千里科技校园招聘智能出行:写在车里的软件
车载业务面对的是一个约束极强的环境:算力有限、实时性要求高、一次升级失败可能影响整车体验。团队通常按「底层驱动—中间件—上层应用」分层协作,新人往往先从某个功能模块的接口联调做起,逐渐理解整条链路上的时序与容错设计。
这条线对候选人的要求偏向系统思维:C/C++ 基本功、对操作系统与内存模型的理解、愿意读大量既有代码。它不轻松,但成长曲线陡。
把一次投递拆成可以走完的路:先看清我们在做什么,再看清岗位要什么样的人,然后一步步填表、准备、面试。这篇长文由人才发展团队与内容编辑一起整理,像 HR 坐在对面,把该说的都说完。
杭州滨江的一间会议室里,上午九点半,白板上画着三条并行的线:一条是车载软件的迭代节奏,一条是工业软件的交付节点,一条是内部平台的版本发布。这是千里科技每周一的项目对齐会。很多人第一次听到「千里科技」,会把它想成一家单纯的软件公司,其实更准确的说法是:我们在做的是让机器与人配合得更顺的那一层——车里的控制逻辑、工厂里的数据流、企业里的协同流程,都属于这个范畴。
千里科技成立于 2013 年前后,从一支做嵌入式与工业控制的小团队起步,逐步把业务拓展到智能出行、智能制造与企业数字化服务三条主线。团队规模目前处于千人级到两千人级的区间,其中研发人员占比通常超过六成,办公地点以杭州为总部,在多个城市设有交付与服务中心。这些数字在页面里只做量级说明,具体编制、办公分布与组织架构,请以千里科技校园招聘官方发布的信息为准。
我们不太喜欢用「愿景」这个词来讲宏大叙事。更愿意这样描述:希望做一家把复杂问题拆得足够清楚、并且愿意对交付结果负责的技术公司。这句话在招聘里意味着什么?意味着我们招人时不只看你会不会写某段代码,也看你能不能把一个模糊的需求讲成一个别人能接手的方案;意味着我们愿意花时间带新人,因为复杂的事情交接需要耐心。
从校园招聘的视角看,一家公司的组织形态会直接影响新人的体验。千人级的团队意味着项目线足够多,你有机会在不同业务之间横向看看;也意味着流程不会像几十人小团队那样随意,文档、评审、发布节奏都是有规矩的。千里科技校园招聘每年开放的岗位方向覆盖研发、硬件、算法、产品、交付与职能支持几大类,各方向的人数配比大致呈现「研发为主、交付次之、产品与职能补充」的结构。
对 2026 届及往届毕业生来说,判断一家公司值不值得投,可以看三个朴素的问题:它做的业务你是否愿意长期了解;它带新人的方式是否具体;它的评价体系是否可预期。这篇长文会把这三件事尽量讲实。
以上为示意性说明,用于帮助理解量级,不构成任何承诺;实际编制、岗位与时间以官方发布为准。

理解业务,比背岗位名称更有用。下面把三条线拆开讲,每条都说明白「解决什么问题、团队怎么配合、新人通常从哪类任务上手」。据行业通行做法,这类技术公司的校招新人,前三个月大多从边界清晰的模块任务开始,逐步过渡到跨模块协作。
车载业务面对的是一个约束极强的环境:算力有限、实时性要求高、一次升级失败可能影响整车体验。团队通常按「底层驱动—中间件—上层应用」分层协作,新人往往先从某个功能模块的接口联调做起,逐渐理解整条链路上的时序与容错设计。
这条线对候选人的要求偏向系统思维:C/C++ 基本功、对操作系统与内存模型的理解、愿意读大量既有代码。它不轻松,但成长曲线陡。
工厂里的问题往往不是算法不够先进,而是数据没有被干净地采集与对齐。这条线的工作包括设备数据接入、产线看板、质量追溯与工艺参数分析。它需要候选人既能写后端服务,也愿意走进车间看一眼设备实际怎么跑。
很多同学投递前会担心自己不懂制造,其实团队里大半人也是从零开始学的,关键是愿不愿意问、愿不愿意到现场。
面向企业内部流程的协同平台、数据中台与效率工具。看似「离业务远」,实际最考验对真实使用场景的理解:一个审批流设计得好不好,用户三五次点击就能感受出来。
这条线适合既懂技术又愿意琢磨人的候选人,产品岗与解决方案岗也多由此延伸。
三条线不是三堵墙。实际项目中,车载业务的数据会回流到工业侧的测试平台,企业数字化的工具又服务于前两条线的交付管理。所以千里科技校园招聘的岗位设置,更接近「以能力为轴、以业务为落点」:你投的是某个方向,入职后仍会在相邻方向上有协作机会。
举一个具体的场景:某条产线的检测工位需要把视觉判定结果同步到整车测试报告里。这件事横跨工业与出行两条线,参与的人既有做设备接入的工程师,也有做测试工具链的工程师。校招新人如果在这类跨线任务里待过一个季度,对系统的理解会比只做单一模块扎实得多。
我们更愿意招「能把问题讲清楚的人」,而不是「简历上关键词最多的人」。前者能长大,后者往往停在原地。 —— 一位参与校招评审的技术负责人,口述整理
需要说明的是,本页对业务线的描述为示意性概括,涉及具体项目名称、客户信息与交付规模的部分,我们不做展开,也请以自己的判断为准,实际信息以官方发布为准。
上述比例为便于理解的量级参考,非精确统计口径。
以上数字为站点内容描述用的量级示例,不代表真实统计、排名或第三方认证。
案例不讲宏大叙事,只讲「问题长什么样、怎么拆、最后交付了什么形态」。三个场景按业务线排列,均为脱敏后的示意性描述。
一条老产线上的设备来自不同年代、不同厂商,通信协议各不相同。项目组做的事,是把这些数据统一接入、清洗、建模,再以看板形式呈现给班组长。听起来像常规集成,难点在于异常值:某台设备在高负载时会输出漂移数据,如果不识别,整张看板的合格率都会失真。
团队最后的做法是给每个数据源加一层健康度评估,把「可信度」作为字段一起传递。这个思路后来被复用到其他项目,也是我们在面试里常用来提问的素材——你如何判断一个数据点值不值得相信。
用户说一句话到系统回应,中间要经过唤醒、识别、语义理解、指令执行几个环节。项目组把端到端的耗时分段埋点,找出最耗时的一段,再做针对性优化。最终体验上的变化很朴素:等待感变短了。
旧系统里一个流程要走七个页面,重构后压缩到三步。产品同学的做法不是画更漂亮的界面,而是先把真实的审批路径画出来,发现有两步是历史遗留、并无必要。删掉比加上更需要判断。
三条业务线原本各有一套测试脚本体系,维护成本高。合并后的工具链统一了用例描述格式,减少重复劳动。这类「不显眼的工程」恰恰是新人最容易参与、也最能长本事的活。
上述案例为脱敏描述,涉及客户与具体指标的部分未做展开;如需了解业务概况,可到 关于我们 页面继续阅读。
下面这组数据来自搜索引擎的相关搜索统计(近 30 天搜索印象),把它们按意图归了类。看清别人在搜什么,比盲目投递更省力。
「千里科技」单独被搜 3,063 次,是全部相关词里最高的一档——说明大量用户还在「认识这家公司」的阶段,企业简介类内容需求最集中。
「招聘」703 次高于「校招」249 次,两词合计 952 次,说明搜索意图已带明确求职目的,但不少人还没区分社招与校招两条通道。
「校园招聘」相关两词合计 441 次,其中「官网」138 次,说明有一批用户已经过了了解阶段,在找「从哪儿正式投」的入口。
数据来源:搜索引擎相关搜索,近 30 天,仅供参考;分组与解读由本站编辑整理,数值未作任何改动。
这一节按能力侧重分类,每一类都写清「平时做什么、看重什么、适合什么样的人」。岗位名称与编制为示意性说明,具体开放情况以官方发布为准。
做服务端逻辑、接口设计与平台能力。日常是写代码、做评审、查线上问题。看重的是基础扎实(数据结构、并发、数据库)、能写清楚的文档、以及遇到线上问题不慌的性子。
建议准备:一个能讲清「为什么这么设计」的项目,比五个只写了技术栈的项目更有说服力。
在资源受限的环境里让程序稳定运行。涉及驱动、通信协议、板级调试。「能上手、肯翻手册、愿意在实验室待到把问题复现」是这条线最看重的东西。
建议准备:把做过的硬件项目里最难的一个 bug 讲成故事,包括你怎么定位的。
从数据里找规律,再把规律变成可上线的模型或规则。这条线容易误解的地方是:大部分时间在清洗数据与评估效果,而不是调参。看重统计基础、工程能力与对业务问题的理解。
建议准备:讲清一个模型的评估口径,比讲清用了什么网络结构更重要。
把模糊需求翻译成可执行的方案。日常是与客户、研发、交付三方沟通,写文档、画流程、做取舍。看重结构化表达与共情能力——能不能听懂对方没说出的话。
建议准备:带一份你主导过的需求文档或竞品分析,讲清结论是怎么来的。
把系统真正装到客户现场并跑起来。需要出差、需要和现场的人打交道、需要在不确定环境里解决问题。这条线成长很快,因为你会见到最多的真实状况。
建议准备:说明你是否能接受阶段性出差,以及你处理突发状况的一次经历。
支撑组织运转的岗位。人力侧重招聘与培养,财务侧重核算与分析,品牌侧重内容与传播。看重细心、责任心与对流程的理解。
建议准备:用一件小事说明你如何把流程做得更顺。
下面这份排序依据「岗位开放量 × 投递集中度 × 准备成本」综合整理,属编辑判断而非官方排名,仅供选择方向时参考。
开放量最大、成长曲线最陡,也最考验系统思维。适合底子扎实、愿意长期啃底层的人。
门槛清晰、路径明确,实验室经历比绩点更被看重。适合动手能力强的同学。
投递最集中、竞争也最激烈。建议用工程落地的视角准备,而非只堆模型名词。
竞争者相对少,但需要愿意跑现场。对跨专业同学友好,学习曲线平缓。
非技术背景可投,但作品要求高。一份清晰的需求文档比十句自我介绍有用。
评分与排序为编辑整理的主观参考,不代表官方评估;岗位开放情况请以官方发布为准。
流程清楚了,焦虑就少一半。下面把每一步的「实际上在发生什么」写出来——很多同学以为自己被刷了,其实只是批次还没推进。
| 阶段 | 你在做什么 | 我们在做什么 | 典型时长 |
|---|---|---|---|
| 网申投递 | 填资料、上传简历、选方向 | 系统校验完整性,人工初筛 | 3–7 个工作日 |
| 笔试 | 线上作答专业与综合题 | 统一评分、划定区间 | 90–120 分钟作答 |
| 专业面试 | 讲项目、答技术追问 | 评估基础与解题思路 | 40–60 分钟 |
| 综合面试 | 聊动机、协作与规划 | 评估匹配度与稳定性 | 30–45 分钟 |
| 结果沟通 | 等待通知、确认意向 | 内部定级、发放通知 | 3–10 个工作日 |
第一件是「投完没动静」。网申提交后进入的是批量筛选,不是实时反馈系统,很多岗位会在截止后统一处理。如果投递后 10 个工作日仍无任何状态变化,可以通过官方渠道礼貌询问一次,不必每天刷新。
第二件是「面试轮次少就等于不重视」。不同岗位的评估轮次配置不同,有的方向两轮就能定,有的方向会加一轮交叉面。轮次多少与结果好坏没有必然关系,把每一轮都当成独立的对话来准备更实际。
如果同时准备论文、实习与校招,建议把网申集中在一个周末完成,避免每天零散花时间。笔试前留出至少两个完整晚上做模拟,面试前一天只做复盘不做新题。据不少同学的反馈,节奏比时长更重要——每天两小时连续两周,通常比考前突击一整天更有效。
关于时间节点的具体说明:本页列出的时长区间为便于理解的典型值,不同年份、不同岗位批次会有调整,请以千里科技校园招聘官方发布的时间表为准,我们不做臆测式的精确承诺。
以上为典型区间说明,非承诺;实际以官方发布为准。
网申表不是行政表格,它是你的第一份书面表达。下面按「一分钟走一遍」的方式,演示怎么把一段平平无奇的经历写得让人愿意继续读下去。
你原来写的是「负责实验室数据采集系统的维护工作」。信息量接近于零——谁都能这么写,评委看完记不住任何东西。
改成「维护 3 套采集程序,覆盖约 40 个传感器通道,重写了其中数据落盘模块」。规模让人有了画面,动作让人知道你真的动过手。
再改成「重写落盘模块后,单次采集丢包率从约 3% 降到 1% 以内,调试时间缩短约一半」。数字用「约」表达区间,既真实又有说服力。
把最想被追问的两段放前面,其余压缩成一行。一页纸的简历,评委平均只会看 30 到 60 秒,把弹药集中在开头。
一是技术栈罗列。写满十几项技能,却没有一处说明「用它做了什么、做到什么程度」。评委更愿意看到「用某框架重构了一个模块,接口响应从 800ms 优化到 200ms 左右」这样的句子。
二是项目描述只有功能没有难点。功能是需求文档就能写的东西,难点才体现你的判断。哪怕难点只是「如何在资源受限的设备上把内存占用压下来」,也值得单独写一句。
三是获奖与课程堆砌。课程列表占掉三分之一篇幅,反而挤掉了项目。四是文件命名混乱,诸如「简历最终版1」这样的文件名,会给筛选环节添不必要的麻烦。
方向选择要明确。第一志愿与第二志愿之间最好有清晰的能力侧重差异,比如一个偏工程实现、一个偏数据分析,这样两份材料可以分别打磨;如果两个志愿几乎一样,等于只投了一个,还分散了准备精力。
联系方式务必核对。每年都有同学因为手机号少一位、邮箱拼错,在结果通知阶段失联。提交前把手机号、邮箱、学校与专业名称各读一遍,是最省时的一分钟。
作品链接用可访问的地址。如果放 GitHub 或作品集,先自己在无痕窗口打开一次,确认没有权限问题。这一条看似琐碎,实际能筛掉不少「点开是 404」的情况。
以上为经验性区间,供参考,非硬性标准。
「在【场景】中,针对【具体问题】,做了【动作】,使【指标】从【A】变化到【B】。」把四项填满,一段经历的基本骨架就有了。
准备不是刷更多题,而是让已有的知识在压力下能被调用出来。下面按笔试、专业面、综合面三段给建议,都是可执行的动作。
技术岗笔试通常包括计算机基础、编程题与部分场景分析题,非技术岗则偏逻辑推理、数据解读与案例分析。多数情况下总时长在 90 到 120 分钟之间。建议开局先扫一遍全卷,把有把握的题标记出来,先做完再回头处理难题。编程题宁可交一个能通过的朴素解法,也不要为了「炫技」写出跑不通的代码。
备考节奏上,考前三到五天每天做一套限时模拟,重点不是分数,而是熟悉「在时间压力下思考」的感觉。错题当天整理成一句话结论,不要抄整道题。
面试官通常会从简历里挑一个项目,然后一路追问下去。比较有效的讲法是四段式:背景是什么、你负责哪一部分、遇到了什么具体困难、最后怎么解决并验证。四段讲完大约两分钟,留出追问空间。避免一上来就讲技术栈清单,那是简历该做的事。
被问到不会的问题时,诚实说明「这块我了解不深,我的推测是……」,然后给出思考路径,比硬编一个答案要好。据多位面试官的说法,能承认边界的候选人往往更值得培养。
这一轮常问「为什么选这个方向」「遇到过分歧怎么处理」「未来三年想变成什么样的人」。回答不需要漂亮,需要具体。比如讲分歧,说清楚当时双方各持什么观点、你做了什么让讨论推进、最后结果如何,比抽象地说「我善于沟通」有说服力得多。
面试结束前的提问环节也别浪费。问一个真正想知道的、关于团队协作方式或新人培养节奏的问题,比问「公司什么时候上市」更合适。
以上时长为常见区间,具体以实际安排为准。
很多人关心「进来之后有没有人带」。答案是有的,但带教不是替你做决定,而是帮你在遇到问题时知道该往哪儿看。
头两周通常是环境与流程熟悉期:代码仓库怎么组织、发布流程怎么走、文档放在哪里、遇到问题找谁。接着会接到第一个边界清晰的任务,规模不大但完整,从需求理解到提交评审走一遍。这个阶段的目的是让你知道「一件事在这里是怎么被做完的」。
导师制是这一阶段的核心。每位新人会配一位同方向的导师,常见节奏是每周一次一对一沟通,聊进展也聊困惑。导师不负责替你写代码,负责在你卡住时指出方向。据不少新人的反馈,前三个月最难的不是技术,而是学会提问——把问题描述清楚本身就是能力。
这个阶段通常会参与跨模块任务,开始接触其他方向的同事。你会第一次感受到「接口约定」的重要性:自己改一处,可能影响别人的调用。也是在这个阶段,新人开始逐步承担小型需求的完整交付。
公司内部一般会有技术分享与文档沉淀的机制,参与分享不是强制任务,但对表达能力的锻炼很直接。把一件做过的事讲给别人听懂,往往比自己做完更能巩固理解。
成长通道大致分两条:一条是技术纵深,往某个方向做得更深;一条是横向拓展,接触更完整的业务链路。两条路没有优劣,关键是看你在哪条路上更有耐心。晋升评估通常结合项目贡献、协作评价与能力维度,具体标准以内部制度为准,本页不做具体承诺。
需要坦诚说明的是,任何培养体系都不能保证每个人都成长得快。有人三个月就上手,有人需要一年。我们更看重的是持续投入的意愿,而不是起步速度。
仓库、文档、发布流程、团队分工,先建立地图感。
从需求理解到提交评审走一遍,导师每周一次沟通。
开始理解接口约定与依赖关系,承担小型需求交付。
结合项目贡献与个人兴趣,确定后续发展方向。

关于待遇,我们不打算写具体数字——校招薪资随岗位、城市、学历与批次浮动,把某一档写成定论反而会误导。下面只讲构成逻辑与环境,具体以官方发布的说明为准。
一般由固定部分与浮动部分构成,浮动部分与绩效评估周期挂钩。不同岗位方向的构成比例不同,研发与交付的侧重点也有差异。具体标准以官方说明与录用沟通为准。
通常包含法定保障项目与补充商业保障,覆盖范围与生效时间在入职时会有明确说明。异地入职的同学一般会有过渡性的住宿或补贴安排,具体以当期政策为准。
包括内部技术分享、外部课程与书籍报销一类的学习支持,以及参与行业交流的机会。这部分的价值不容易量化,但对前两年的成长影响不小。
办公区以开放式工位为主,配安静的电话间与讨论室。研发高峰会有加班,项目间隙节奏相对平缓。坦诚地说,任何技术公司都难以做到绝对准时下班,重要的是节奏可预期。
我们在页面上不放具体薪资数字,也不写「年薪多少万起」这类话术。原因很简单:这类数字一旦写死,就有被误读为承诺的风险,而实际录用沟通会综合岗位、城市与评估结果。与其给一个可能落空的预期,不如把构成讲清楚,让你在沟通环节问对问题。
如果你在沟通环节收到正式说明,建议重点确认三件事:固定与浮动的比例、试用期的评估方式、以及异地安排的细节。这三项问清楚,基本就不会有意外。
本页不列具体金额,避免误读为承诺;一切以正式录用说明为准。
用第一人称讲几段日常,比任何宣传语都更能说明问题。以下人物为用于说明工作场景的虚拟角色,不代表真实履历。
车载软件 · 入职第 2 年
「我第一年最常做的事是读代码。一开始很不适应,觉得没在『创造』。后来发现,能读懂别人写的东西,才知道该往哪里加东西。」
工业软件 · 入职第 1 年
「第一次去现场,看到自己写的看板被班组长真的在用,还提了三条意见。那一瞬间比任何评审通过都踏实。」
产品方向 · 入职第 3 年
「产品岗最难的不是画原型,是敢删。旧流程里有两步没人说得清为什么存在,删掉之后反而顺畅了。」
算法方向 · 入职第 1 年
「入职前以为每天都在调模型,实际大部分时间在确认数据对不对。把数据搞干净,模型效果往往自己就上来了。」
以上为用于说明内容分工与工作场景的虚拟角色,不代表真实员工履历、职务或机构信息。
据公开资料与行业普遍认知,我们把公司发展的几个关键阶段整理如下。不虚构可核实的奖项或排名,仅作脉络梳理。
由嵌入式与工业控制方向的团队组建,早期业务以定制化项目为主,逐步形成交付方法论。
从单一项目交付走向产品化,开始沉淀可复用的平台组件,团队规模进入百人级。
面向智能出行方向投入研发,建立车规相关的流程与测试体系,业务结构由两条线拓展为三条。
完善导师制与内部技术分享机制,校招规模逐年扩大,新人培养流程逐步标准化。
围绕智能出行、智能制造与企业数字化继续打磨产品与服务,校招岗位方向保持稳定。
以上数字仅用于描述本站内容规模与校招常见量级,不代表真实用户量、访问量、排名或第三方背书;滚动数字为页面展示效果。
据行业通行做法,校招匹配度往往不取决于学校排名,而取决于「你的准备方式」与「岗位的真实工作形态」是否对得上。下面三类人的痛点与收益,写得具体一些。
痛点:简历上只有一个课程设计,面试时不知道该讲什么,容易在追问下露怯。
用千里科技校园招聘的岗位说明反推准备方向后,可以挑一个方向做一份完整的个人项目——从需求到测试走完,哪怕规模很小。收益是:你终于有了一段能讲满两分钟的经历。
痛点:担心被「专业不对口」直接筛掉,不清楚该投哪个方向。
工业软件与数据方向对跨专业更友好,因为它更看重问题拆解与现场理解。把原专业的视角当优势写出来,往往比硬补技术栈更有效。
痛点:觉得技术公司只招工程师,产品与职能岗不知道怎么准备。
产品、交付与职能支持方向都有校招通道。准备一份能体现结构化表达的文档,比如一份流程改进分析,比背岗位职责更有用。
以下问题来自宣讲会现场提问与线上留言的整理,答案写得比结构化摘要更细一些,包含背景与注意事项。
多数情况下,毕业两年内、尚未正式就业或处于择业期的毕业生,可以按应届生通道投递。判断依据通常看是否签订过正式劳动合同、是否有连续社保缴纳记录,而不是单纯看毕业证上的年份。
需要提醒的是,往届生通道与应届生通道在批次安排上可能不同,部分岗位会优先处理当届批次。如果你的毕业时间较早,建议在网申备注里写清楚毕业时间与目前状态,减少筛选环节的来回确认。具体口径每年可能微调,以当年官方发布的招聘公告为准。
一般在投递截止前可以修改,但如果该岗位已经进入筛选或面试安排阶段,反复变更会带来沟通成本。比较稳妥的做法是:提交前把关键信息核对两遍,提交后只在确有实质变化时更新,比如新增了实习经历或补上了作品链接。
如果变动涉及联系方式、投递方向这类关键字段,建议同时通过官方邮箱说明一次,避免系统状态与实际不一致。修改不等于加分,稳定清晰的材料比频繁更新的材料更受青睐。
技术岗通常以计算机基础、编程题与场景分析为主,编程题数量多在 2 到 3 道之间;非技术岗则以逻辑推理、数据解读与案例分析为主。整体时长常见区间为 90 到 120 分钟,具体以当期通知为准。
作答策略上,建议先把有把握的题目全部拿下,再回头处理需要长时间思考的题。编程题以「能跑通、边界正确」为第一优先级,不必在有限时间里追求最优解。考前一周每天一套限时模拟,通常比临时抱佛脚更有效。
通常建议同时投递不超过 2 个方向。两个志愿之间最好有明确的能力侧重差异,比如一个偏工程实现、一个偏数据分析,这样两份材料可以分别打磨;如果两个志愿几乎重合,等于只投了一个,还分散了准备精力。
排序上,把最想去且准备最充分的方向放第一志愿。第二志愿可以选一个竞争相对缓和、但你同样愿意去的方向,作为兜底而不是凑数。
常见安排是专业面与综合面两轮,部分方向会加一轮交叉面,总计两到三轮。每轮之间的间隔通常在 3 到 7 个工作日,全部流程走完大致需要 2 到 4 周。
如果间隔超过两周仍无消息,可以通过官方渠道礼貌询问一次进度。等待期间不建议停止准备——把上一轮被问到但没答好的问题复盘一遍,是这段时间性价比最高的事。
可以。两类岗位编号不同,评估维度也不同:实习岗更看重学习潜力、可投入的时间长度与上手速度;正式岗更看重项目的完整度、你能否独立推进一件事到交付。
如果时间允许,先走实习再转正式的路径在不少方向上都存在,但具体是否开放转正、需要满足什么条件,以当期政策为准。投递前请核对岗位编号,两类岗位的编号常常只差一位,看错会耽误时间。
其他问题可查看 联系我们 页面,或到 关于我们 了解企业概况。请通过正规渠道了解与投递,本页不提供任何非官方的内推代投服务。
如果你已经想清楚要投哪个方向,建议先把简历按上面的四步改写一遍,再核对岗位编号,然后通过官方渠道提交。过程中有任何疑问,都可以写信过来,我们会尽量在几个工作日内回复。
本页信息为整理与示意,岗位、流程与时间以官方发布为准;请勿通过非官方渠道提交个人证件信息。
读者评论与求职反馈
来自同学的留言,保留了原本的语气。评论内容为读者个人经验,不代表官方口径。
网申里项目经历那段照着这里的建议改成结果导向,把「负责数据清洗」写成了「清洗约 12 万条日志,接口异常定位时间从半天缩到 1 小时」,第二天就收到了笔试通知。
想问下千里科技校园招聘的笔试是线上还是线下?我报的是嵌入式方向,页面里只写了题型没写时长,有知道的朋友吗。
去年投的算法岗,一面聊项目聊了四十分钟,没让我手写快排,倒是追问了模型上线后怎么监控,这块建议提前准备一下。
作为家长看完了整页,写得比较实在,没有那种「年薪百万」的夸张话,孩子照着流程一步步准备,心里有底不少。
建议简历控制在一页,我第一版两页半,HR 提醒后压缩到一页,重点反而更清楚了。
导师制那段是真的,入职后有个师兄带着看代码,前两周基本在补基础,节奏不算快,适合我这种底子一般的。
投递前一定要核对岗位代码,我差点把实习岗投成正式岗,两个编号只差一位,看错了挺耽误事。
希望多讲讲产品经理岗的面经,技术岗的资料挺全,非技术那条线还差点意思。