A4 · 付费试做任务包(四个方向)

内部 docs/templates/A4-付费试做任务包.md

A4 · 付费试做任务包(四个方向)

用途:选拔第 5 步 • 每位候选人限做本方向 1 道题 版本:v1.0 ⚠️ 必须付费。 这是真实劳动,不付费就是变相白嫖,法律与口碑风险都不可接受。


〇、通用规则(发给候选人前必须写明)

项目 规定
时间预算 5-8 小时(上限 8 小时,超出部分不要求完成,也不影响评分)
完成周期 收到任务后 7 个自然日内提交
交付方式 提交代码压缩包 + README(或提供 Git 仓库链接)
报酬 固定【待定】元 / 次(约合【待定】元/小时,对得起你 5-8 小时的投入)。归属招聘成本,不占人力成本额度
支付时点 提交后 5 个工作日内支付,无论是否通过评审
试做环境 使用你自己的电脑与环境,不得使用我方任何真实代码或数据
允许使用 官方文档、搜索引擎、你自己的历史代码
禁止使用 AI 编程助手(Copilot / ChatGPT / Claude / Cursor 等)、他人代做、直接复制开源项目
诚信声明 提交时须附一句话声明:"本任务由我独立完成,未使用 AI 辅助工具生成代码。"
代码归属 试做任务的成果归我方所有;你保留在个人作品集中非商业展示的权利
数据要求 不得使用任何真实用户数据;如需数据请自行构造

为什么禁 AI 而允许搜索? 因为搜索是"查资料",AI 生成是"替代你思考"。我们要评估的是你自己现在的能力水平——如果 AI 代做了,进来之后你会很痛苦,我们也会很痛苦。 实践中如何验证:面试时会针对你的提交代码做追问("这块为什么这么写""如果改成 X 会怎样"),答不上来即判定为代做。

通用评审标准(五维,与 A2 试做评审表一致)

评审项 权重 说明
可运行性 30% 能否按 README 顺利跑起来
完整性 25% 功能点是否齐全、边界是否处理
可读性 20% 命名、结构、注释、有无调试残留
说明文档 15% README 是否说清怎么跑、做了什么、已知问题
自测意识 10% 有无自测记录、测试用例、截图

README 必须包含的四段(写进任务说明)

# 项目名
## 1. 如何运行
(环境要求、安装命令、启动命令,让别人能照着跑起来)
## 2. 我做了什么
(实现了哪些功能,哪些没做,为什么)
## 3. 自测情况
(怎么验证的,截图/日志/测试结果)
## 4. 已知问题与我的取舍
(哪里做得不够好,如果时间更多会怎么改)

第 4 段是加分项。 能主动说出自己不足的人,通常更值得带。


一、后端方向试做任务

任务名称:实现一个"文件上传与元数据查询"接口

背景

我们的系统需要支持用户上传附件(图片/PDF),并能在后续按条件查询自己上传过的文件。请实现一个简化的后端服务。

交付要求

必须实现(60 分)

  1. 一个 HTTP 接口 POST /files,接收文件上传
    • 校验文件大小(上限 5 MB)和类型(仅允许 jpg / png / pdf)
    • 校验失败时返回明确的错误码与错误信息
    • 上传成功返回文件 ID
  2. 一个 HTTP 接口 GET /files,支持按文件类型和上传时间范围筛选,返回文件列表
  3. 一个 HTTP 接口 GET /files/{id},返回文件元数据;文件不存在时返回 404
  4. 文件存储用本地目录即可(不需要接对象存储)

建议实现(25 分)

  1. 至少 4 个单元测试,必须包含异常分支(超大文件、错误类型、不存在的 ID)
  2. 统一的错误响应格式(例如 {"code": "...", "message": "..."})
  3. 简单的请求日志(记录时间、接口、耗时、结果)

加分项(15 分,任选)

  1. 分页支持
  2. 并发上传的幂等处理(相同文件不重复存储)
  3. 接口文档(Markdown 或 OpenAPI 均可)

技术约束

  • 语言/框架自选(Python+FastAPI / Java+Spring Boot / Go+Gin / Node.js+Express 均可)
  • 可以用 SQLite / 内存 / JSON 文件做元数据存储,不要求装数据库
  • 不得引入需要复杂配置的中间件

我们不希望你做的事

  • ❌ 不要为了"显得高级"引入 Redis / MQ / Docker 编排——简单能跑 > 架构漂亮
  • ❌ 不要花时间做前端页面
  • ❌ 不要超过 8 小时

我们重点看什么

观察点 说明
异常处理 会不会想到"如果用户传了个 100MB 的 exe 会怎样"——这是最核心的观察点
错误码设计 是否区分了"参数错"和"系统错"
测试意识 有没有测异常分支,而不只测成功路径
说明文档 README 能不能让一个陌生人跑起来
代码结构 有没有把"路由/业务/存储"分得清清爽爽(不要求分层架构,但不能全塞一个文件)

常见不合格信号(面试时会追问)

  • SQL 用字符串拼接 → 无安全意识,需重点评估
  • 没有任何错误处理,"传什么都能存"
  • 测试只测了成功路径
  • README 只有一句"运行 main.py"
  • 代码里有 print("111") 之类的调试残留

二、前端方向试做任务

任务名称:实现一个"任务列表页"(含三态与交互)

背景

我们的产品里有一个任务列表页,需要展示任务标题、状态、创建时间,并支持筛选和操作。请实现这个页面。

交付要求

必须实现(60 分)

  1. 从本地 JSON 文件(随任务提供)读取任务数据并渲染为列表
  2. 完整处理三种状态:
    • 加载中(骨架屏或 loading 提示)
    • 空数据(给用户明确的说明和引导,不能是白屏)
    • 加载失败(错误提示 + 重试按钮,点击能重新请求)
  3. 按状态筛选(全部 / 进行中 / 已完成)
  4. 每条任务有一个"标记完成/取消完成"按钮,点击后界面状态同步更新
  5. 列表按创建时间倒序

建议实现(25 分)

  1. 搜索框(按标题模糊搜索),输入时做防抖处理
  2. 无结果时给出不同于"空数据"的提示文案
  3. 至少 1 个可复用的组件(例如状态标签、空状态组件)

加分项(15 分,任选)

  1. 响应式布局(手机宽度下可正常使用)
  2. 用原生 JS 之外的框架实现(Vue / React),并说明选型理由
  3. 关键操作有简易的无障碍支持(键盘可用、aria 标签)

技术约束

  • 可以用原生 HTML/CSS/JS,也可以用 Vue / React
  • 不得引入大型 UI 组件库来"直接调出"整个列表(可以用,但你需要能解释每一处配置)
  • 数据用提供的 JSON,不需要写后端

我们不希望你做的事

  • ❌ 不要做登录、注册、路由等无关功能
  • ❌ 不要追求视觉效果而忽略状态完整性——状态完整性比好看重要
  • ❌ 不要超过 8 小时

我们重点看什么

观察点 说明
三态是否真的都做了 这是最核心的观察点。只做成功路径的候选人占大多数
防抖是否理解 是复制粘贴的,还是能解释"为什么需要"
状态管理 点击"完成"后,界面是否真的同步(而不是只改了按钮样式)
组件复用 有没有识别出可复用的部分
代码组织 数据请求、状态、渲染是否混在一起

常见不合格信号

  • 只有成功路径,加载和错误状态完全没考虑
  • 点击按钮后列表顺序错乱或状态不一致
  • 全部逻辑塞在一个 300 行的 index.html 里
  • 防抖函数复制过来但用错(例如把防抖用在了"立即显示结果"上)

三、测试方向试做任务

任务名称:为"登录 + 找回密码"功能设计并执行测试

背景

随任务提供一份简化的需求文档(约 1 页)和一个可运行的简易演示程序(一个 Docker 镜像或本地脚本,可选)。请你针对这个功能设计测试用例并执行测试,输出缺陷报告。

交付要求

必须实现(60 分)

  1. 测试用例表(Excel / Markdown / CSV 均可),每条包含:
    • 用例编号、所属模块、用例标题、前置条件、操作步骤、预期结果、优先级(P0/P1/P2)
  2. 用例需覆盖:
    • 正常流程(登录成功、找回密码成功)
    • 异常流程:密码错误、账号不存在、账号被锁定、验证码错误/过期、密码不符合规则、重复提交
    • 边界值:密码长度上下限、验证码有效期临界、连续错误次数临界
  3. 缺陷报告(至少 3 条,可以是你在测试过程中"假设"发现的问题,但必须写成规范格式):
    • 缺陷标题、严重程度、复现步骤、预期结果、实际结果、影响范围
  4. 一份测试总结(1 页以内):测了什么、没测什么、为什么、遗留风险是什么

建议实现(25 分)

  1. 用例总数 ≥ 30 条,且异常用例占比 ≥ 40%
  2. 用 curl 或 Postman 对登录接口做实际的参数边界测试,并附上测试记录

加分项(15 分,任选)

  1. 把核心回归用例用脚本自动化(Python / JS 任一,能跑就行)
  2. 做一次简单的越权测试思路说明(例如 A 用户能否用 B 用户的凭证找回密码)

需求文档(随任务提供,示例摘要)

  • 用户可用"手机号 + 密码"登录
  • 密码规则:8-20 位,必须包含字母和数字
  • 连续输错 5 次,账号锁定 30 分钟
  • 找回密码:输入手机号 → 获取短信验证码(6 位,5 分钟有效)→ 输入新密码 → 完成
  • 同一手机号 60 秒内只能获取一次验证码

我们不希望你做的事

  • ❌ 不要写长篇的测试理论——要的是具体用例,不是教科书
  • ❌ 不要为了数量堆重复用例("密码错 1 位""密码错 2 位"这种拆成 20 条没有价值)
  • ❌ 不要超过 8 小时

我们重点看什么

观察点 说明
异常与边界覆盖 这是测试岗位的核心能力。"只测正常流程"直接判定不合格
缺陷描述质量 复现步骤是否任何人照着做都能复现(这是最硬的指标)
优先级判断 是否理解"哪些必须先测"
测试总结 能否诚实说出"我没测什么"——这体现职业素养
用例可维护性 编号、分类、分层是否清晰

常见不合格信号

  • 用例只有 10 条且全是正常流程
  • 缺陷报告写"登录有问题"(无法复现)
  • 用例预期结果写"登录成功"(太笼统,不可判定)
  • 没有区分优先级,30 条全是 P0

给候选人的提示:这个岗位最值钱的能力不是"会点",而是能想到别人想不到的情况。请大胆假设刁钻的场景。


四、产品 / UI 设计 & 技术文档方向试做任务

任务名称(二选一,报名时说明偏好)

选项 A:把一段混乱需求整理成规范需求文档 + 线框图

背景:随任务提供一段"客户口述"的混乱需求(约 300 字,逻辑跳跃、前后矛盾、夹杂未说明的前提)。

示例(节选):

"我们想加个功能,就是用户能传文件上来,然后呢别人也能看到,但是不是所有人都能看到啊,得看权限,管理员肯定都能看,普通用户只能看自己的,还有那种共享的……哦对了文件大了怎么办,我们之前就有人说传不上去,还有要能删掉,删了之后还能恢复吗这个你看着办,最好手机上也能用……"

交付要求(必须,60 分)

  1. 需求澄清清单:列出你需要向客户确认的问题(≥8 条),并说明每个问题为什么重要
  2. 需求文档:包含背景、目标用户、功能清单(含优先级 P0/P1/P2)、每个功能的验收标准
  3. 关键流程说明:用文字或流程图描述"用户上传文件"的完整流程(含异常分支)
  4. 线框图:至少 3 个页面的低保真线框图(手绘拍照、Figma、PPT 均可),需标注:加载中 / 空 / 错误 / 无权限 四个状态

建议实现(25 分)

  1. 明确写出"本次不做什么"(范围边界)
  2. 标注每一条需求对应的用户价值(为什么用户需要它)

加分项(15 分)

  1. 提出一个客户没说但你认为必须有的功能,并说明理由
  2. 指出原需求中的矛盾之处并给出处理建议

选项 B:为现有系统编写一份"新人 30 分钟上手"技术文档

背景:随任务提供一个真实(但已脱敏)的小型开源项目的代码仓库,要求你阅读代码后编写一份开发环境搭建与代码结构说明文档。

交付要求(必须,60 分)

  1. 环境搭建文档:从零到能跑起来,每一步都要有命令和预期输出
  2. 代码结构说明:目录是干什么的,核心模块之间的关系
  3. 常见问题(≥5 条):新人最容易卡在哪里,怎么解决
  4. 实测验证:请找一位同学(非本方向)按你的文档实操一遍,记录他卡住的每一步,并据此修订文档

建议实现(25 分)

  1. 画一张架构图或模块依赖图
  2. 标注文档中"我不确定"的部分(诚实比假装懂重要)

加分项(15 分)

  1. 提交"实测验证"的记录(对方卡住的原始描述)
  2. 提出对原项目 README 的改进建议

我们不希望你做的事

  • ❌ 不要用大量专业术语堆砌——清晰 > 专业
  • ❌ 不要交付一份"看起来很完整但读不懂"的文档
  • ❌ 不要超过 8 小时

我们重点看什么

观察点 说明
结构化能力 能不能把混乱信息整理成有条理的清单
边界意识 选项 A:有没有主动界定"不做什么";选项 B:有没有标注不确定的部分
可执行性 文档别人照着能不能做成事(这是文档的唯一标准)
状态完整性 线框图有没有画出加载/空/错误/无权限——只画正常界面是不合格的
表达清晰度 有没有错别字、编号断裂、图文不一致

常见不合格信号

  • 需求文档把客户原话照抄一遍,没有澄清与结构化
  • 线框图只有"正常显示"一种状态
  • 文档写完自己都没实际验证过
  • 出现明显错别字、序号重复、章节编号断裂(本岗位的失职)

五、任务发放与回收流程(TL 执行)

步骤 动作 负责 时点
1 向通过技术面的候选人发送任务说明(含 README 模板) TL 面试后 1 个工作日
2 确认候选人已收到并理解规则(特别是"禁用 AI""必须付费"两条) TL 同上
3 中途不提供技术帮助(但可回答"规则类"问题,如格式、提交方式) TL 全程
4 收件并登记(代码包 + README + 诚信声明) TL 截止后
5 按 A2 试做评审表打分 TL + 对应方向工程师 2 个工作日
6 支付试做报酬(无论是否通过) 财务 提交后 5 个工作日内
7 通知结果:通过→进入录用;不通过→致谢并说明是"本次不匹配"而非"你不行" TL 支付同步
8 试做代码归档(不通过者的代码也需归档,作为对比基线) TL —

第 6 步不可省略,也不可延迟。 学生之间会交流,一家公司如果试做不付费,消息会在校内传开,后续招募成本会剧烈上升。


六、试做任务评分汇总表

候选人 方向 可运行(30) 完整(25) 可读(20) 文档(15) 自测(10) 总分 结论 是否已付试做费
/100 ☐通过 ☐待定 ☐不通过 ☐

通过线:总分 ≥ 60,且"可运行性"≥ 18 分(跑不起来的一律不通过)。