5.27机考后给候选人超长走心刷题&备考建议

结合 5.27 本场机考,我给大家写一份完全贴合 OD 风格、不走弯路、零基础也能学会的刷题与机考建议。

一、一星题到底该怎么练?

一星题占 200 分,是及格保命分,必须稳拿。

高频考点:字符串处理、哈希表、模拟、排序、边界判断

必练场景

  • 空字符串、空输入
  • 重名、重复编号、后缀规则
  • 数量超限、范围越界
  • 非法字符、非法格式过滤

刷什么最有效

LeetCode Hot100 + 剑指 Offer 足够!

不用刷难题,就刷简单 + 中等,重点练代码规范和边界处理。

很多同学机考不是不会,是平时没养成处理边界的习惯

二、二星题一定要死磕DP!

本场二星唯一考点:动态规划

OD 机考里,二星题 80% 都是 DP:路径 DP、背包 DP、带约束 DP、区间 DP。

看到这些数据直接 DP

  • n≤2000、m≤200
  • 选 m 个、最大 / 最小和、距离约束
  • 求方案数、能否到达

必刷经典题

  • 62. 不同路径
  • 64. 最小路径和
  • 198. 打家劫舍
  • 518. 零钱兑换 II

千万别碰:DFS、回溯、暴力枚举 —— 大数据量必超时。

三、机考现场最实用的应试技巧

  • 先画流程图,再敲代码 模拟题尤其重要,流程清晰 = 少写 80% bug
  • 先判断合法性,再写主逻辑 空值、非法、超限、越界,前三行就处理完
  • 本地自测至少 3 组用例 正常用例、边界用例、非法用例
  • Python 用 list 模拟栈 / 队列特别香 代码短、不容易错、可读性高
  • 注意时间与内存 O (n²) 在 n=1e5 必超时;C/C++ 注意不要超 256MB
  • 四、机考过后:综测、HR面、技术面怎么准备?

  • 综测:100 题,保持前后一致,选积极正向,不乱选就稳过
  • HR 面:不刁难,重点问:空档期解释、求职动机、城市选择、薪酬预期
  • 技术面:手撕简单题 + 测试八股 + 项目细节,准备好都能过
  • 主管面:聊职业规划、稳定性、部门匹配度,轻松聊就行
  • 最后我想说

    OD 不卡学历、不卡出身、不卡空档期,只看你稳不稳、细不细

    不用刷很难的题,不用搞懂高深算法,把基础打牢、把边界写全、把 DP 练会,你就能超过 80% 的人。

    如果你是双非、考研失利、脱产、零基础想进大厂,别犹豫,OD 真的很适合你。

    后续我会持续分享 OD 机考、面经、offer 进度,欢迎一起交流~

    #华为od##上岸大厂##机考##内推##求职#
    全部评论
    接offer
    1 回复 分享
    发布于 昨天 11:42 广东

    相关推荐

    在我来鹅之后,接到的第一个完整大需求就是需要编写一个skill,之前的实习也写过一些skill,但是在我的理解中skill就是跟提示词没差,把你需要的目标全写上就好了,所以第一次mr我提交了一个超过1200行的md,被mt打了回去,为了完成这个需求,我又赶紧请教了我身边的大神同学,获取一些写skill的经验,将原先1200行的md进行了对应的references拆封,又通过我朋友教我的验证机制验证这个skill的效果,最后完成了我的第一个需求。正好前两篇文章给大家分享了写好的用来包装简历的skill,那么今天来给大家分享怎么去写一个好的,可以实际用来工作的skill,摆脱只会写提示词的尴尬。构建 Skill 的五个步骤Step 0:先写 EvalsEval(Evaluation,评估)是一套结构化的、可重复运行的测试用例集,用来判断 Skill 的表现是否符合预期。它不是泛指"测试一下",而是开发 Skill 的前提条件。一个典型的 Skill eval 集至少包含三类用例:- 正例(Positive):用户说“帮我看一下这个 PR 能不能合”,验证 Skill 应该被加载- 负例(Negative):用户说“帮我把代码格式化一下”,验证 Skill 不该被加载——路由别跑偏到不该触发的地方- 边界(Edge):“这个 PR 改了一行日志,要不要审”,验证边界情况下的路由行为正例和负例都要写,而且负例往往比正例更值钱——误触发是 Skill 路由的头号失败模式。Eval 不只是测一次。Perplexity 的 eval 分三个层次:如下图每种都要在 GPT、Claude Opus、Claude Sonnet 不同的 orchestration 模型上分别跑——Sonnet 和 GPT 的 Skill 行为差异很大,只在一种模型上过了不够。没有 evals,你改 description 就是在盲改,一个新 Skill 也可能悄悄搞坏已有的十个 Skill。Step 1:写 Description(最难的一行)description 是路由触发器,不是文档。写好它不需要关心 Skill 的内容,只需要关心能不能在正确的时间加载、有没有意外触发到不应该触发的地方——误触发是头号失败模式,每加一个 Skill 都有可能让其他 Skill 变差。糟糕的 description 描述 Skill 做什么,好的 description 说什么时候加载。举个监控 PR 的例子:不要写这个 Skill 做什么,要写工程师感到焦虑时会说什么——"babysit"、"watch CI"、"make sure this lands"。快速检查清单:- 以"Load when…"开头- 控制在 50 词以内- 描述用户意图,最好来自真实查询- 不总结工作流程Step 2:写 Body跟同事讲工作流程和跟 LLM 讲工作流程完全是两回事。对几乎任何面世超过一年的软件工具,只要提名字,模型已经知道怎么用。所以跳过模型已经懂的部分。不用写出每一步命令。比如不要写 git log → git checkout main → git checkout -b clean-branch → git cherry-pick commit。写 "Cherry-pick the commit onto a clean branch. Resolve conflicts preserving intent. If it can't land cleanly, explain why." 模型在后者上表现好得多,尤其是事情不按预期走的时候。太规定的指令比灵活的指令更脆弱。然后聚焦 gotchas 和反例,它们是最高信噪比的内容。每次 Agent 搞砸了就加一条,gotcha 会自然地累积起来。条件逻辑或内容太重的东西移出 SKILL.md,放到 accessory file 里渐进加载。Step 3:用层级结构- scripts/ —— 确定性逻辑,模型不用每次重新发明- references/ —— 重型文档,条件触发才读("如果 API 返回非 200,读 api-errors.md")- assets/ —— 输出模板,模型直接复制填充- config.json —— 首次运行设置,问一次保存下来对于极其复杂的 Skill,进一步考虑是否应该拆成一组 Skill,用 depends: 声明加载关系。Step 4:迭代切分支出来,在无 Skill 的状态下跑 hero query(核心用户场景查询),建 eval 集,反复调。提交 review 时最好一个 changeset 里自带 eval 集。Description 里的小词改动对路由影响很大,甚至会 spillover(溢出)到其他 Skill,所以这些在 Step 5 之前做完。Step 5:发布大家快把这5步实行起来,成为写skill专家吧!
    琉璃梦忆:直接skill creator 管你这那的
    AI了,我在打一种很新的...
    点赞 评论 收藏
    分享
    评论
    3
    3
    分享

    创作者周榜

    更多
    牛客网
    牛客网在线编程
    牛客网题解
    牛客企业服务