前端四轮速通字节ssp(专升本)

很多小伙伴对最终结果很感兴趣,结果我放在评论区了,之前发的小红书帖子

这场小红书前端社招一共四轮。最让我意外的是,几乎每一轮都花了很多时间在聊项目和作品。

我不是标准履历:专升本背景,过往找工作也遇到过学历筛选。所以这篇想记录的不只是题目,也想说说:如果背景不够漂亮,怎么用作品把面试聊起来。

我的作品集/开源主页在这里,后面提到项目时可以对照看: https://github.com/tt-a1i

先说结论

  1. 常规场景题会问,但这次真正展开的是项目。
  2. 作品要能现场打开、能讲清楚取舍,而不是只写在简历上。
  3. 手写题这块我发挥很差,3 道题都没写出来,但后面还是靠作品继续聊下去了。
  4. 对非标准背景的人来说,作品集是一个很重要的补充证明。

一面,1h30min

  1. 自我介绍。
  2. 展示自己的项目和作品,这部分占了超过一半时间。
  3. 常规前端场景题。
  4. 手写 3 道:前端场景题 2 道,算法题 1 道。我这轮确实没写出来,也坦诚说了自己现在大量使用 AI Coding,平时更关注工程落地、产品思路和项目实现。

二面,40min

  1. 自我介绍。
  2. 继续介绍作品。
  3. 全程基本围绕作品展开:为什么做、解决什么问题、技术上怎么设计、有没有真实使用场景。

三面,1h

  1. 常规自我介绍。
  2. 因为我是专升本背景,个人经历聊得比较多。
  3. 作品展示依旧占据大部分时间,面试官会顺着项目继续追问。

四面,40min

  1. 没有再做完整自我介绍。
  2. 直接进入作品展示。
  3. 围绕作品聊了一些更发散的问题,比如项目定位、技术取舍、后续规划。
  4. 最后问有没有觉得自己没展示到的内容,我就继续补充介绍作品。但时间比较紧,还有一些没完全展开。

我的一点复盘

这场面试给我的感受是:项目不是简历上的装饰,它真的可能变成面试的主线。

尤其是背景不算标准的时候,单靠学历和履历不一定能让人快速建立信任。但如果你能把作品拿出来演示,讲清楚自己为什么做、怎么做、遇到什么问题、怎么解决,面试官就会更容易从“标签”转向“能力”。

我觉得准备作品时,至少要准备这几件事:

  1. 项目能现场打开,最好有线上地址或 GitHub。
  2. 能用 1 分钟讲清楚它解决什么问题。
  3. 能讲清楚 2-3 个关键技术点。
  4. 能讲清楚你做过哪些取舍,而不是只说用了哪些技术栈。
  5. 能讲清楚项目下一步还想怎么迭代。

最后

如果你也在准备前端社招、作品集,或者和我一样是非标准背景,欢迎在评论区交流。我不一定有标准答案,但可以把自己准备作品、讲项目、用开源项目补充履历这一路踩过的坑尽量讲清楚,也可以帮你一起看看项目该怎么表达。

#大厂面试问八股多还是项目多?##我的求职进度条##简历中的项目经历要怎么写#
全部评论
牛,向大佬学习
点赞 回复 分享
发布于 昨天 22:44 江西
怎么又字节了?标题和内容不对称,骗人的吧
点赞 回复 分享
发布于 昨天 15:41 江西
感谢分享,你这条路能走通,给了我很大启发,我也是空有项目弱算法和学历,我想我以后也可以这么干
点赞 回复 分享
发布于 昨天 10:47 河北
天呢!太牛啦
点赞 回复 分享
发布于 昨天 10:02 北京
应届生?
点赞 回复 分享
发布于 昨天 00:28 青海
大佬有大厂经历吗
点赞 回复 分享
发布于 05-27 22:55 广西
https://www.xiaohongshu.com/explore/69ed7471000000003701cc74?xsec_token=ABAFSmcw7_4ywCWlFg9jJ24mykTuWmgfc8HK-Q-M4MxA4=&xsec_source=pc_user
点赞 回复 分享
发布于 05-27 10:11 上海
所以这是拿到offer了吗
点赞 回复 分享
发布于 05-27 10:07 北京
过了么
点赞 回复 分享
发布于 05-27 10:07 江西

相关推荐

在我来鹅之后,接到的第一个完整大需求就是需要编写一个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了,我在打一种很新的...
点赞 评论 收藏
分享
评论
10
19
分享

创作者周榜

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