DevCN
菜单
社区成员个人主页
成员
DEV CN / 成员主页

宋国卿

查看宋国卿发布的技术文章、关注圈子与公开讨论。

242技术文章207关注圈子841圈内发布0关注者
COMMUNITY POSTS

交流圈发布内容

作者在不同技术圈子中的观点与讨论

1
# 求职与面试

你对自己未来的职业定位是什么?

我的定位是'技术+业务+管理的复合体':不是一个纯写代码的执行者,而是'用技术持续为公司创造价值的经营型工程师'。短期——做深技术、扛起关键业务、成为团队依赖的攻坚力量;中期——走向技术负责人,能带团队、做架构决策、对齐业务战略;长期——成为能把'技术、业务、组织'三者打通的人。无论 AI 怎么变,'持续解决问题的价值定位'不变,变的只是实现方式。

2
# 求职与面试

如果 AI 最终能写 99% 的代码,你会去做什么?

我会把精力 100% 转到 AI 做不了的那 1% 及它的放大器上:①定义'该做什么'——从模糊的商业诉求里提炼正确的问题和方案;②做'判断和责任'——为关键决策拍板、为结果负责;③做'人与组织的连接'——理解业务、协调团队、把技术价值落地成商业成果;④设计和管理 AI——决定用什么工具、怎么用、边界在哪、如何保证质量和安全。与其焦虑'写代码被取代',不如提前成为'驾驭 AI 的决策者'。

3
# 求职与面试

你的学习方法是什么?如何保持竞争力?

'目标驱动 + 输出倒逼输入':①先明确要解决什么问题,再针对性学,不漫无目的刷教程;②'输出倒逼'——通过写博客、做分享、带人、做项目来检验自己真懂了没,教是最好的学;③'实践优先'——能上手就不只看,用小项目验证理解;④'保持源头'——读一手资料(官方文档、源码、论文)而不只看二手解读。竞争力来自'持续解决真实问题',而不只是'知道很多'。

4
# 求职与面试

面对 AI 持续进化,你如何应对不确定性?

策略是'拥抱变化 + 加固不变的能力':拥抱——主动用、持续学,不抗拒新工具,让 AI 成为杠杆而不是对手;加固——把时间投向 AI 难以替代的能力:判断力、系统思维、业务理解、协作领导力、高质量的知识与经验积累。我不预测'AI 什么时候取代谁',只确保'无论工具怎么变,我解决问题的能力持续增值'。不确定性不可怕,可怕的是能力停滞。

5
# 求职与面试

五年后你希望自己成长成什么样的人?

五年后我希望成为'能独立扛起一块业务的技术负责人':既能做架构决策、保障系统稳定,又能带团队、对齐业务,把技术翻译成商业价值。在 AI 时代,我希望自己不是'用得最溜的人',而是'能判断 AI 该用在哪、怎么用才安全有效的人'——从'写代码的人'进化成'驾驭技术解决问题的人'。具体的路径:深耕领域深度 + 补管理/业务能力 + 持续拥抱新工具。

6
# 求职与面试

你的代码出过最严重的问题吗?怎么收场的?

(示例框架)坦诚:有。一次我在配置中改错了开关,导致部分用户短暂无法下单。我第一时间回滚、止损,服务很快恢复;随后我完整复盘,发现根因是'配置变更没有走评审和验证流程'。我推动了改进:配置变更强制评审 + 预发环境验证 + 配置监控告警,从此再没出过同类问题。我的态度是:问题不可怕,'不透明、不改进'才可怕。这次经历反而让我的风险意识更强。

7
# 求职与面试

你如何验证自己的假设而不是想当然?

习惯用'数据/实验/回读'三重验证:①关键假设先找数据或做小实验验证,不凭感觉;②写完的代码用测试和真实运行验证,不'想当然认为对';③重要结论用'另一种方式'交叉验证——比如算完再估算、读完再复述,发现盲点。我给自己定规矩:凡是'会影响结果'的判断,都要求'可验证的证据',避免'我以为'代替'事实'。

8
# 求职与面试

你会怎么处理团队里的隐性风险?

主动'看见并暴露'隐性风险:①常问'如果 X 出问题会怎样',主动做压力测试、故障演练,把隐患提前暴露;②关注'没人愿意提的'问题——技术债、单点依赖、人的瓶颈、交接隐患;③建立'风险清单'并定期复盘,而不是'没人说就当没有';④营造'敢报风险'的氛围——鼓励大家提前说,不因为'报风险'被责难。隐性风险最怕的是'沉默',我的做法是主动打破沉默。

9
# 求职与面试

你怎么看待'快'和'稳'的平衡?

我认为'快'和'稳'不是对立,而是'不同阶段侧重不同':产品探索期——快更重要,允许试错、快速验证;成熟期——稳更重要,稳定本身就是竞争力。关键不是'二选一',而是'用技术手段同时兼顾':用灰度、开关、快速回滚让'稳'也快得起来,用自动化让'快'也不容易出错。我会根据业务阶段主动调整平衡点,并让团队清楚'这个阶段我们优先什么'。

10
# 求职与面试

发布前你会做哪些风险评估?

四类:①影响面——这个改动影响哪些服务、哪些用户、会不会级联;②变更风险——改了哪些关键路径,能否回滚、回滚多快;③容量风险——新功能会不会带来流量/存储/连接压力;④时序风险——是否有依赖的发布顺序。评估后我会定'灰度策略'(小流量先上、观察再放量)、准备'回滚方案'、设好'监控和告警',并明确'什么情况算异常、怎么响应'。发布不是'一键上线',是'可控的变更'。