面试问题整理

技术类:
1、redis如何水平扩展(一致性哈希)
2、parallelStream使用中的问题(线程安全,聚合与否,共享线程池问题)
3、dubbo的实现原理,调用过程,dubbo异步调用实现
4、future原理
5、jvm加载过程(校验,加载,空间分配,静态变量,静态方法等)
6、双亲委派机制
7、线程池常用核心参数,以及设置原因(IO密集型线程,CPU密集型线程)
8、redis为什么单线程,如何保证效率的(单线程只是用来连接)
9、redis的一些命令
10、redis的数据类型
11、jstack,jmap等线上排查问题工具,用法
12、Linux常用命令 (z)grep ,cat ,sed ,awk ,wc(统计),去重等
13、如何查看异常挂掉的进程日志
14、数据库事务 隔离级别,默认隔离级别,实现原理(mvvp)
15、数据库索引 主键索引,单列索引,组合索引,唯一索引(聚簇索引),覆盖索引;全文索引(非聚簇索引);命中逻辑,结构(B+树,适合区间查询,只在叶子节点存有数据,单节点能存更多数据,减少IO)
16、锁:乐观锁,悲观锁,各种锁,以及不同应用(如JAVA,MySQL)中的实现喝可用库
17、数组下标,为什么从0开始?数组的地址真的是连续的嘛?数组在栈还是堆上?(栈,jvm内存模型)多个进程共享的时候,如何保证数组在内存中的地址是连续的?
18、hashmap的推演及变形问题
19、spring 事务(@Transanctional)的实现原理
20、

方案类:
1、分布式锁
2、幂等(最终一致性)
3、128位数字加减问题(数据结构如何设计,用什么基础类型,位数是否足够,怎么处理符号位)
4、计算10000或者更大数字的阶乘问题(算法,溢出,如何判断溢出)

技能:
1、load飙高的常见排查思路

来自 Google 官方的代码评审最佳实践-摘录

  • 文章地址
  • CR的标准
  • 在 CR 中要看些什么
  • 如何浏览这次改动(CL)
  • Review 的速度
  • CR 要多快?
  • 速度 vs 中断
  • 快速回应

文章地址

原文地址:https://mp.weixin.qq.com/s/zIiDk7rcIKgvqh0YAvQPaA

英文地址:https://github.com/google/eng-practices/

CR的标准

  • Reviewer 有责任保证CL的质量,作为Review的代码的Owner
  • Reviewer不应追求完美,而应追求持续改进
  • CR要具有指导意义
  • 代码风格应该与现有的一致。如果项目没有统一风格,那就接受作者的风格
  • 解决冲突难以达成共识时,需要面对面或者拉起更大的团队讨论,带上Leader

在 CR 中要看些什么

  • 代码经过完善的设计
  • 功能性对于使用者们是好的
  • 对于任何UI改动要合理且好看
  • 任何并行编程的实现是安全
  • 代码不应该复杂超过原本所必须的
  • 开发者不该实现一个现在不用而未来可能需要的功能
  • 代码有适当的单元测试
  • 测试经过完善的设计
  • 开发者对于每样东西有使用清晰、明了的命名
  • 注释要清楚且有用,并只用来解释why而非what
  • 代码有适当的写下文件(一般在g3doc)
  • 代码风格符合style guide
  • 确保你查看被要求review的每一行代码、确认上下文、确保你正在改善代码质量,并赞扬开发人员所做的好事与优点吧!

如何浏览这次改动(CL)

步骤1: 用宏观的角度来看待改动,查看CL描述以及它做什么步骤2: 检查CL主要的部分步骤3: 用合理的顺序看CL 其余的改动

Review 的速度

为什么 Review 速度要快?

在Google我们优化开发团队 共同生产产品的速度,而不是优化个人开发的速度。个人的开发速度很重要,但它不如整个团队的开发速度重要。

CR 如果很慢,则:

①、团队整体的速度下降。

②、开发人员开始抗议 cr。

③、代码质量会收到影响。review 慢时,开发者提交的压力大。

CR 要多快?

如果你并没有处于需要专注工作的时候,那么应该在 review 完后尽快修改。回复最长的极限是一个工作日。

速度 vs 中断

我们可以在投入到处理他人给的review评论之前,找个适当的时机点来进行cr。这有可能是当你的当前开发任务完成后、午餐、刚从会议脱身或从微型厨房回来等等。

快速回应

个人回应评论的速度,比起让整个 cr 过程快速结束更重要。

 若在整个过程中能快速获得来自 reviewer 的回应,大大减轻开发者对缓慢 cr 过程的挫败感。

 reviewer员要花足够的时间来进行review,确保他们给出的LGTM,意味着“此代码符合我们的标准”。

 理想的个人的回应速度还是越快越好。

后端开发能力模型(后端)v1.0

能力模型(后端)
   T3T4T5T6T7T8
岗位职责业务能力业务梳理和设计Xa. 能清晰的梳理和描述完整的业务流程,理解并指导开发工作b. 能指出明显的业务流程错误和不足a. 能发现业务流程中较深入的问题a. 帮助业务方设计合理的流程b. 用逻辑和数字作为辅助工具a. 使用数字和逻辑主动发现流程问题b. 主动推进流程的设计和改进 
开发能力




需求分析a. 能理解并分解小规模的需求并指导开发小规模 < 3pda. 能理解并分解中等规模的需求并指导开发中规模 < 10pda. 能理解并分解大规模的需求并指导开发大规模 < 30pd经验要求. 领导3个以上 10~20pd级别的项目a. 能理解并分解超大规模需求并指导开发超大规模 >= 30经验要求. 领导3个以上超过30pd的项目a. 有能力领导超过100pd的需求经验要求. 领导过5个以上超过50pd的项目 
架构设计XXa. 能理解架构设计原理b. 能理解自己参与的系统架构c. 能设计小规模的系统架构d. 能在设计中考虑并处理高并发问题/大数据量问题a. 深入理解架构设计和常用模式b. 能进行大规模的系统架构设计或大规模系统重构经验要求. 参与3个以上部门内系统架构的设计与实现,并至少负责其中1个子系统的设计与实现a. 能主导设计部门级系统架构b. 能参与规划公司的架构模型和演进方向c. 在设计中充分考虑并平衡 业务要求/可扩展性/并行开发能力/高并发要求/大数据量要求/高可恢复性 等经验要求. 领导3个以上部门内架构的设计与实现经验要求. 参与制定过部门级的年度技术规划a. 能主导设计公司级别的系统架构经验要求. 领导2个以上跨部门系统架构的设计与实现经验要求. 参与制定过公司级的年度技术规划
详细设计和编码a. 能理解设计的目的和常用设计模式,范式/反范式b. 能够使用UML图/ER图等工具c. 规避并处理常见的边界问题/异常问题等d. 代码严谨并符合代码规范e. 能够进行简单的领域建模a. 熟练掌握设计过程和工具b. 能在设计中考虑并处理幂等问题/一致性问题c. 代码高效d. 能处理基本的性能优化e. 熟练掌握常用的领域建模方法并用于实践a. 代码优雅,可扩展性强b. 掌握性能优化的常用规律和方法,能处理日常遇到的绝大多数性能问题c. 能优化领域模型或者重构a. 除个别case外完全处理日常遇到的各种技术问题和性能问题b. 具备丰富的领域建模经验,理解业务本质经验要求. 编写或抽取系统核心代码或核心结构,有效的提升开发效率和可读性经验要求. 编写过框架/中间件级别代码,能高效的处理一类业务问题 
测试a. 掌握单测和集成测试方法b. 构思工作中的测试方法并实现a. 掌握测试的常见场景和方法,能快速识别风险和影响范围,给出高效的测试方案b. 积累日常测试的工具和用例a. 设计相对长期的测试方法和测试用例,提升测试效率b. 掌握从可测试行角度出发设计和实现的能力c. 能从测试的角度出发影响详细设计和编码a. 能从测试的角度出发影响架构设计  
前端技能      
运维技能a. 能合理埋点和设置监控b. 使用shell/python分析问题c. 习惯性查看监控/日常并处理问题a. 高效的排查和解决问题b. 积累日常运维的工具和用例a. 能梳理和设计高效的监控体系/日志体系   
技术技能a. 基础过关,能熟练使用常用框架b. 知道常用组件的使用方法c. 知道常用中间件的使用方法a. 了解常用中间件的原理并用于排查问题a. 深入理解常用中间件中的至少一类b. 能够快速学习新知识技能,直接用于简单的日常应用a. 有擅长的技术,熟知其实现和原理,在团队内形成优势互补a. 是某一领域的专家,公司内解决该问题的大拿 
领导能力制定标准XX经验要求. 领导制定过团队内的标准经验要求. 参与制定过部门内的标准经验要求. 参与制定过公司级别的标准 
团队管理Xa. 能指导低级别工程师进行日常开发a. 有能力带领2-3人b. 敢于公开表扬a. 有能力带领5人以上的团队b. 了解每个人的能力,为每个人制定发展规划并实施c. 敢于维护公司的价值观并用于团队管理a. 有能力带20人以上的团队 
通用素质学习能力 a. 能快速了解任务和简单业务b. 能快速学习一个技术的用法a. 能迅速并深入理解新的业务和系统 a. 理解技术领域的最新动态并推进团队使用b. 对使用的技术有体系性的认知,在某一方面有特长并持续学习  
逻辑思维 a. 具备基本的逻辑思维能力和数字感b. 能简单的用于日常工作a. 能理解具备一定深度的逻辑链条 a. 能主动作有一定深度的逻辑思考b. 能利用手边的工具获取数据证明自己的观点a. 主动用严密的逻辑来规划工作和方案b. 具备用全面而恰当的数据证实或者证伪的能力  
沟通能力 a. 能在team内分享技术和业务,时间不少于30分钟a. 能在团队内分享技术和业务,时间不少于1个小时b. 能掌控并转换自己的表达方式以让对方听懂a. 在团队内做过有深度的分享,描述清楚并让大家听懂经验要求. 领导3个10pd以上跨团队项目的沟通工作a. 具备面试更低级别工程师的能力经验要求. 领导3个30pd以上跨团队项目的沟通工作经验要求. 做过公司级的分享经验要求. 领导5个以上超过50pd的跨团队项目的沟通工作