字节测开(一面) 已感谢

杂活算重复性点点点+没含金量的工作吗，还是说有更广泛的划定范围。我现在mt是将他自己的需求拆解多个部分给我做，然后叫我写个文档给他看，然后晚上跟我讲一遍写需求的流程，这个算杂活吗但实习的需求太散了，面试的时候肯定拿不出手，肯定还是要自己包装

转眼入职新公司一周啦有时候不敢相信命运就在一瞬间就会改变我放弃了原先想去的南方城市来到了山东的海边目前的工作让我感受到前所未有的轻松公司里几乎都是女生….都是年轻人….没有谈资论辈…没有严格的上下级关系….还有同事们都很热情…从公司走五分钟就能看到海….从出租房走五分钟到公司…也许是这半年我把坏运气都用光了这一切都意外的顺利短短几天就让我确定了 我想一直在这个公司呆下去的想法没有打压和pua 没有试用期裁员 没有优化 没有复杂的人情关系 一切都好像梦一样还有人问我是不是进外企了 哈哈哈总之 命运的齿轮开启的让我应接不暇原来自己想要的生活只需要月薪4k就能实现我想要的不过就是出门能看到海、有一个自己的温暖的小屋、有份舒心的工作，周末和朋友见一面，天天吃不同的好吃的外卖。更重要的是 身心的舒服和自由 完完全全掌握自己的生活…这就够了也许有时候会看到有人觉得我放弃了计算机这行 我会后悔 替我不值。但我想说 人生是自己的 知道自己现在过的不错 那就够了。我们的社会文化总是告诉我们要着眼于未来 但却完了眼前可获得的快乐 希望大家都能冲破思想的桎梏。找到属于自己的价值观。加油👏

简历发邮箱：**********地点：上海虹桥公司：汽车行业-智驾方向岗位：JAVA开发工程师（数仓方向）工作职业1. 参与数仓指标体系建设- 基于业务需求，使用 SQL 和 UDF 开发数据指标计算任务，构建企业级数据仓库。- 优化数仓模型，提升数据质量和查询性能，支持业务决策分析。2. 数据集成与 ETL 开发- 使用 Seatunnel 开发数据同步任务，实现跨源数据（如 MongoDB、业务库）的抽取、清洗和转换。- 基于 DolphinScheduler 设计和调度数据处理工作流，确保任务稳定运行。3. 业务埋点体系开发- 参与设计业务埋点方案，跟踪用户行为数据，支持产品优化和运营分析。- 开发埋点数据采集、清洗和入库的全流程处理逻辑。4. 技术协作与问题排查- 与后端团队协作，基于 Spring 框架开发数据服务接口。- 使用 Doris 等 OLAP 引擎优化指标查询性能，解决数据处理中的疑难问题。岗位要求：1. Java 编程基础扎实，- 熟练掌握面向对象编程（OOP），包括类、继承、多态、接口等概念- 深入理解 Java 容器类（如 List、Map、Set 的实现原理）- 熟悉多线程编程和常用设计模式2. 数据库与 SQL- 精通 SQL，包括复杂查询、索引优化、窗口函数等- 熟悉 MySQL 数据库设计和调优，了解事务隔离级别3. 后端开发框架熟练使用 Spring/Spring Boot 框架，理解依赖注入（DI）和 AOP 原理掌握 MyBatis 或其他 ORM 框架的使用4. 有大数据基础- 了解大数据组件 Hadoop 生态（HDFS、YARN、MapReduce）- 熟悉 Flink 或 Spark 的基本原理和使用场景- 掌握 SeaTunnel（或类似 ETL 工具）的数据同步开发5. 数据仓库知识- 理解数仓分层架构（ODS/DWD/DWS/ADS）- 掌握维度建模方法（星型 / 雪花模型）- 了解 OLAP 数据库（如 Doris、ClickHouse）的特点和适用场景

鼠鼠第一次投大厂面试,写面经攒人品:1. 个人介绍(2min)2. 挖项目(我跟后端相关的项目似乎只有抖音商城(字节跳动青训营),他一直挖我这个项目)3. 服务是怎么被发现的?(微服务)4. 假如你这个服务要更新,要更平滑,不让用户感到延迟,你会怎么做?- 维护两套环境（蓝：当前生产环境；绿：新版本环境）。- 新版本在绿环境测试通过后，切换流量到绿环境，蓝环境作为回滚备用。- 优点：零停机，用户无感知切换。5. 你输入一个url的处理过程6. 然后就开始写题了,面试官直接口述,输入一个数字,输出下一个最小的比这个数大的数字(重新排列)leetcode类似的题目是:[556. 下一个更大元素 III](******************************************************)这道题手撕还是相当紧张的,给我撕出来了7. 数据库事务是什么8. mvcc是什么,怎么实现的?9. 场景题,给你一个番茄小说的书,有十万订阅,如何快而准确的通知到所有订阅的人更新了(这里要求你去用具体的实现)我这里寄了,后面复盘的时候,应该是使用feed流,这个是用ai写的答案:- 推模式 (Fanout-On-Write/Writes)：- **操作时机：** 当关键事件（如新章节发布）发生时**立即**执行。- **目标用户：** **核心活跃粉丝（数量相对较小）**。- **动作：** 将事件**直接写入**这些目标粉丝的个人 **收件箱（Inbox Feed）**（一个按时间排序的数据存储）。用户访问自己的 Feed 流时，直接从这个收件箱拉取即可，延迟极低。- 拉模式 (Fanout-On-Read)：- **操作时机：** 当用户主动请求访问 Feed 流时执行。- **目标用户：** **非核心粉丝（长尾粉丝，数量大）** 或 触发推模式的粉丝，在访问 Feed 时可能需要拉取更长时间范围内的数据。- **动作：** 后端服务在用户请求时，**实时聚合**用户所关注对象（收藏的书籍）的 **发件箱（Outbox Feed）** 数据（包含所有发布事件），按时间排序后返回给用户。这需要访问多个发件箱（每个收藏的书一本）并聚合。- **「推拉结合」的关键：** **合理区分「核心粉丝」与「长尾粉丝」**，只对核心粉丝进行实时写入。**关键组件与流程详解：**1. **事件源 (Event Source)：**- **新章节发布：** 最核心的事件源。携带 `bookId`, `chapterId`, `publishTimestamp`。- **粉丝关系变更：** 用户收藏 (`favor`) 或取消收藏 (`unfavor`) 一本书。携带 `userId`, `bookId`, `action`, `timestamp`。2. **事件总线 (Event Bus)：**- 使用高吞吐、可靠的消息队列如 Kafka/Pulsar。接收上述事件并进行持久化，供下游消费者订阅。后面是就是针对十万用户的进行**精准界定“核心活跃粉丝” (`HotFanCache`)：**,查询优化,**高性能存储与分片：**10. 反问,问了业务是什么,技术栈是什么,然后和面试官聊的蛮开心的,面试官夸了基础好,知道稳了10min之后,hr通知2面.1面成功.