-
团队管理
你带过多少人团队？没有标准答案, 主要是要明白面试官想得到什么信息
推荐回答:
我最多带过 15 人左右的研发团队，包括后端、前端和测试。
日常除了技术方案设计，还负责需求排期、代码质量、线上稳定性以及人员培养。
我比较重视"模块负责人机制"，会把系统拆分给不同 owner，避免团队过度依赖单点。
如何评价一个工程师？
基础能力: 技术能力, 业务理解, 沟通理解 ( 技术行不行, 任务能不能完成)
中级能力: 主动性,责任心 (能不能解决问题, 能不能推动项目)
高级能力: 成长性,如何处理绩效差的人？
主要是看绩效差的原因:
技术问题: 技术栈, 岗位匹配
目标不清晰: 目标模糊造成的,
态度问题: 提醒,谈心
管理问题: 管理者,下发的任务反复;
调整之后,依然没有改善, 调整和优化团队出现冲突怎么处理？
技术方案冲突、分工责任冲突、沟通情绪冲突、工期排期冲突、新旧架构改造冲突、代码规范 / 评审冲突;
对事不对人：只讨论方案、逻辑、风险，不评价人品、能力、态度。
以业务和技术合理性为标准：不搞资历压制、不搞派系站队。
私下先沟通，再公开讨论：避免在群里、评审会公开互怼，激化矛盾。
数据 / 代码 / 架构说话：Java 开发用性能、可维护性、扩展性、兼容性、线上风险做依据，不靠嘴吵。
小冲突当场解，大冲突升级负责人：组员能解决不上升，解决不了立刻到技术组长 / 架构师 / 项目经理。-
项目管理
项目延期怎么办？① 先分析延期原因,需求问题, 技术低估,还是外部依赖导致
② 提前暴露风险,不能等到了上线前才反馈延期
③ 如果发现风险,优先做范围拆分,确保核心功能上线,非核心功能后续迭代
④ 增加人力, 调整模块 owner, 技术方案降复杂度 ,减少非关键需求,尽可能减少延期
⑤ 复盘时,会重新梳理整个问题的原因, 是评估,沟通还是流程问题,避免同类问题重复出现需求问题: 解决方案: 需求评审, 需求具体化, 需求变更冻结
技术低估: 需求预研, 拆小任务,引入buffer,优先解决高风险模块
外部依赖: 尽早识别, 明确owner,周期性同步,降级方案, 升级风险
需求频繁变更怎么办？
1. 需求评审阶段, 可以改, 开发中允许小改,不允许大改;
2. 评估开发成本,影响,风险,
3. 同时技术上尽量采用模块化,配置化设计,降低变更成本
一定要改的话.必须让业务知道: 改需求是有成本和风险的, 业务愿意承担就行如何做技术排期？
① 先做需求拆分(底座,模块等),拆分到可评估的粒度
② 识别风险点,
③ 按优先级排序
④预留缓冲时间,
⑤ 持续跟踪,动态调整资源和优先级-
招人 & 培养
你怎么面试别人？简历筛选: 技术匹配度
技术: 八股文,会找几个问一下
项目: 主要看,表达是否清晰, 逻辑逻辑是否融洽
场景: 是否具备解决问题能力
如何培养新人
第一阶段: 帮助新人快速融入团队,了解项目,业务背景
第二阶段: 从小任务开始, 小bug, 一般性工单
第三阶段: 逐渐增加任务复杂度, 同时定期沟通,帮助其建立技术习惯和问题分析思路, 逐渐让他负责独立模块,培养 owner 意识。
培养新人最主要的是培养他能独立解决问题的能力如何留住核心员工
识别核心员工
能独立解决问题, 能带动团队效率,有owner意识,能稳定关键系统, 能培养别人
满足成长诉求
给机会(更复杂的项目,架构设计,决策),避免长期重复性劳动
优秀的人除了想挣钱之外还想变得更强
给空间和信任
给决策权, 允许试错,
控制团队消耗
控制无意义的消耗, 无意义的会议, 低效的流程, 反复修改的需求
长期激励:
钱
长期收益
成长空间
影响力跨部门沟通
产品和技术冲突怎么办？
冲突是正常,因为两者关注点不同;
首先要统一目标,是上线还是稳定;
然后告知风险,或者提供替代方案(分阶段上线,或者技术降级)
对于安全性和核心稳定性,以及合规性,坚持原则老板要你做一个不合理需求怎么办？
核心: 不直接对抗，也不盲目执行,帮老板看到成本、风险和更优方案。
① 先理解真正的目标和需求
② 这么做的成本和风险有哪些
③ 给出替代方案
如果还是要做, 那就做, 如果涉及安全,合规,说明底线问题, 避免后续更大的损失-
决策能力
技术路线有分歧你怎么拍板？① 明确目标,哪种方案更有利于目标
② 明确当前面临的问题
③ 综合 成本,风险,性能, 团队能力 做出判断一定要给出一版,避免长期无法推进
出事故谁负责？
① 先止血, 恢复服务,降低影响
② 定位原因 (代码问题, 没有codereview, 没有充分测试)
③ 系统性改进 (如何避免再次发生)
管理者的责任: 流程 规范, 风险控制
如果故意绕过规范,隐瞒问题,严重违规 那必须要处理