后端选手，不着急快速攒钱，重点还是关心职业发展和以后跳槽，想在技术方向多发展几年拼多多：10-10-6，(n+5)×18，主站toC业务，并发高，可能技术前景比较好腾讯：10-8-5，n×15，云相关业务，有点偏解决方案或者运维，可能涉及架构设计、售前、交付，整体开发任务不多2个可能都是最低档白菜，总包大概差十来万，但时薪鹅还小高一些。如果短期内没有快速攒钱的需求，更多看重职业发展和以后跳槽想请教各位佬该怎么选，想奔着业务和技术发展方便后面跳槽去多多又怕敬业，以及有鹅选鹅在这种情况是否还适用

如果只能说一个好处，我觉得是：它能让你在面试时，不再像一个等着老师打分的“学生”，而像一个来谈合作的“职场人”。没实习过的学院派小白，面试时往往是在背书：死磕概念，满口理论模型，生怕答错一个知识点，眼神里写满了“考官求放过“。而实习过的你，面试时其实是在复盘：因为你见过真实的业务流程，知道代码在测试上跑通和在项目里运行是两码事；你被甲方虐过、被Deadline追过，知道比起理论，领导更看重能提出解决问题的完整方案的能力。这种体感会给你一种天然的自信。当面试官问你一个难题时，你不会慌张地背定义，而是会从容地说：“我之前的实习中也遇到过类似的情况，当时我们的处理逻辑是……” 你们说的不再是“知识点...

三、核心技术场景考察及候选人表现（一）考察场景高并发秒杀场景：1 万人同时抢购 100 个库存的商品，要求保证用户体验、系统稳定性与扩展性（二）候选人方案及面试官质疑候选人核心方案：前端先获取 token（通过 Lua 脚本实现锁机制），再凭 token 下单；后续考虑通过 MQ 异步处理、库存分片等方式优化面试官核心质疑点超卖与少卖风险：Lua 脚本仅解决锁竞争问题，下单环节的复杂逻辑（风控等）可能导致下单失败，已分发 token 会造成少卖；锁机制无法完全避免超卖系统扩展性不足：面对 1000 万人抢 1 万个商品的场景，数据库难以承载高并发读写，token 机制与数据库扛压能力不匹配异步...

1.自我介绍2.项目3.如何设计redis连接数 不了解4.各种技术栈选型 kafka clickhouse doris 等5.sql调优6.大表加索引要注意什么问题 锁表7.表的内存碎片化率8.需求发布流程9.反问