2026 Q2-Q3 找 remote SDE 经历 - (1)

去年的相关帖子: https://www.1point3acres.com/bbs/thread-1134743-1-1.html

楼主又来了，继一年前找工上岸之后，在新公司待了一年，结果新公司又倒了，顿时感觉自己是行业冥灯，SaaS公司真的被AI冲击到了。。。没办法，重新interview吧。好在一年前才准备面试过所以还比较熟，但还是重刷了相当的Leetcode，毕竟AI时代，大家coding技能都在退化。。。然后复习了SD，主要还是面senior / staff， backend / full stack backend leaning / platform / AI agent roles.

好的方面，感觉比一年前的职位多了很多，感觉面试机会几乎多了50%，所有公司都在往AI agent转向，backend or general SDE or AI Agentic postions 比去年多了很多。楼主在南方州所以只找remote，主要找startup，所以在湾区和纽约的小伙伴应该机会更多得多。

3个月高强度接触了108家公司，到第一轮技术面有32家，到final round 17家， 拿到3个offers.

菜如楼主像一块生铁被各个公司各个行业的面试官反复拷打，虽然我不是M，但是还是学到了很多很多。前中期总是有某一轮面的不好。不过后来也是被打磨好了，心态也麻了，发挥也变好了。

第一篇先讲 coding(Python为主), 文章可能比较长, 使用了AI 润色，推荐在电脑上看。
（Disclaimer： 分享心得为主，strong bias, 楼主水平有限, 不当之处欢迎指正）

一、前置筛选环节的变化
1. Criteria Assessment（认知 + 性格测试）

• 智商测试（50 题 / 15 分钟）：基本失效了，因为大家都用 AI。
• 性格测试：可能还有点用，至少 AI 代答的动机没那么强。

2. Online Coding Assessment（OA）
越来越少，主要留作初筛。
3. Take-home Assessment

• 做一整个 full stack 项目的越来越少了——大家都用 AI 的话，interviewer 很难据此分级。
• 现在更常见的形式：限时 1 小时，在 CodePad 里 debug 或加一个 feature，然后下一轮做 present + follow-up questions。

二、Live Coding 面试的出题类型
LeetCode 类型（按出现频率排序）

类型	热度
Stack、BFS、Greedy、Topological Sorting	🔥🔥🔥🔥
DFS / Recursion	🔥🔥🔥
Heap	🔥🔥
OOD（Object-Oriented Design）	🔥🔥

OOD

• 经典题还是要过一遍：parking lot, elevator。
• 熟悉 Python 的表达工具: dataclass, Enum, registry class、state transitioning class。
• 有余力再优化：把不同职责的 service 抽出来（separation of concerns）。
• Concurrency：
• • 单实例、多线程 → threading.Lock
  • 分布式系统 → Redis 分布式锁，并且要主动讲 lock + TTL（防死锁）

出题方式

• 1 小时 1~2 道题。
• 更常见的是 1 小时 1 道题 + 1~2 个 follow-up，题型和十年前区别不大。
• 这轮倒是没遇到问 LRU Cache 的公司，哈哈。

Python Go over Tips

• 随机与数值：random.shuffle / sample / choices / uniform；divmod、math.ceil
• 矩阵操作：用 zip(*matrix) 做转置。
• Concurrency：GIL / asyncio vs multithreading vs multiprocessing
• • 重点是什么时候用哪个
  • 一个容易答错的点：CPU-bound 但 low traffic 的场景，由于Process 的 pickle 序列化开销，仍然可以考虑 multithreading，不一定非上 multiprocessing。面试时能主动说出这个反直觉的取舍，很加分。

遇到过的Leetcode真题
.google  и

题号	题目	考点
LC 227	Basic Calculator II	Stack
LC 53	Maximum Subarray	Greedy / DP
LC 56	Merge Intervals	Sorting / 区间合并
LC 210	Course Schedule II	Topological Sorting
LC 340	Longest Substring with At Most K Distinct Characters	Sliding Window
LC 21	Merge Two Sorted Lists	Linked List
LC 88	Merge Sorted Array	双指针（从后往前）
LC 281	Zigzag Iterator	Iterator 设计
LC 169	Majority Element	Boyer-Moore 投票
LC 443	String Compression	原地双指针（RLE 变体）
LC 290	Word Pattern	双向 Hash Map
LC 399	Evaluate Division	图 / Union-Find
LC 341	Flatten Nested List Iterator	Stack / 惰性求值
LC 1971	Find if Path Exists in Graph	BFS / DFS / Union-Find

三、Practical Exercise Coding
下面 8 类是我这轮遇到的practical questions, 感觉这类题有增多的趋势，是好事

1. 现场写一个调用 3rd Party API 的 function
例：给定几个 stock symbol，列出 high / low / average price 并做 aggregation。现场自己查文档（如 https://finnhub.io/docs/api）。
套路是两段式：

• 先把功能跑通——别一上来就炫技；
• 再谈 API best practice：timeout、rate limit、retry、backoff with jitter

第二步才是考点。能主动说出「retry 要设 max attempts」「backoff 要加 jitter 避免惊群」「哪些错误可重试、哪些不可重试」。

2. AI-assisted LeetCode
例：implement the RLE (run length encoding)。这类题考的不是你会不会写，而是你怎么用 AI 并对结果负责。标准流程：先讲思路 → 再让 AI 写 → 然后你 review 并讲解。
1. Explain your thoughts to the interviewer FIRST
2. Ask AI to implement it
3. Review the AI output yourself, then explain it back to the interviewer

Follow-up: make the RLE above support streaming processing
→ You propose the idea (use `iter` and `yield`, ...), then ask AI to implement

3. PR Review 型：并发 + 异步事件（Inbox / Outbox）
给你一个文件，里面有若干 function，藏着复杂的 concurrency 问题和 async event 的 inbox / outbox 问题，15~20 分钟内 fix。
需要熟悉的概念清单：
transactional inbox / outbox
database atomic commit
tenant isolation
retry backoff, max iteration, jitter

asyncio: to_thread, gather, sleep, Semaphore, TaskGroup

Lock concepts — when to use which:
  SELECT ... FOR UPDATE
  SELECT ... FOR UPDATE SKIP LOCKED
  UPDATE ... SET ... WHERE ...
  INSERT INTO ... VALUES ... ON CONFLICT ... DO NOTHING

这块内容展开可以单独写一篇。不过也可以直接去问你的 AI，它应该能把这些考点讲明白。

4. PR Review 型：缓存一致性
同样是给a class, and some func，症状是「不同用户看到的数据不一样，结果不一致」。
考点非常明确：

• 把 in-memory cache 换成 Redis cache（多实例下本地 dict 必然不一致）；
• 想到 idempotency key；
• 用 Redis 锁住 read-write pattern，并且带 TTL；
• 金融场景必须用 Decimal，不能用 float：

e.g Decimal(data).quantize(Decimal("0.01"), rounding=ROUND_HALF_UP)

5. PR Review 型：通用重构

• 重复的 function / class → 抽成通用基类，用 inheritance；
• 用 REGISTRY dict 做类的注册与分发；
• 用 decorator，把 class 作为参数传入。

6. 大 Codebase 快速加一个功能
这类题可以用 AI,但必须有套路。我的感受是:不管 interviewer 还是 interviewee,其实都还没想清楚「正确的标准」是什么。这里分享一套我验证过，能过面试的方法，抛砖引玉。
核心心法两条:Making incremental progress,以及动手做重要功能前先和面试官确认。
还有一句要先立住的定位:AI 在这里是「加速器」,不是「代驾」。它帮你快速读代码、定位、生成,但判断、决策、和面试官沟通是你。面试官考的是你的思路和判断,不是 AI 的输出——所以别闷头让 AI 生成 500 行再一起看天书。

. ΧStep 1 — 你和 AI 同时开始读题
你自己读,尤其是 README;同时让 AI 也开始读。目标是快速建立全局认知。
You are an experienced staff engineer joining this codebase.
Read the README.md and map the top-level directory structure.
Summarize: what this service does, the tech stack, and where the
core business logic lives.

Step 2 — 摸清数据模型,同时向面试官澄清
找到并理解主要的 database table schema、实体之间的关系,判断哪些 file / function 不用改、哪些要改。同时向面试官提澄清问题(需求边界、验收标准)。
List the main domain models/entities and their relationships
(foreign keys / how they connect). For the feature I need to add,
which existing files/modules are relevant, and which are unrelated?

Step 3 — 先找参考,再把计划说出来
大 codebase 加功能的核心是顺着现有 pattern 走,别自创一套。先找一个相似的现有功能当模板,再规划。

3a — 找现有 pattern 参考:
Find an existing feature similar to what I need to add. Show me
how it's structured end-to-end (API → service → data layer) so I
can follow the same pattern.

3b — 说出计划(Speak out loud,得到认可再动手):
Based on that pattern, outline a plan to add [feature]: which files
to create/modify, and the key steps. Don't write code yet.

这一步是「先确认再动手」的落点——把方案讲给面试官听,得到认可,再进 Step 4。

Step 4 — 小步实现
Implement the feature following that existing pattern. Keep the
change focused (within 200 lines if possible) and match the codebase's
conventions. Keep docstrings to a single line.

Step 5 — 主动想正确性 / edge case
不是每道题都关于并发——真正要想的是这道题的正确性难点:错误处理、边界条件,以及如果这段代码会并行执行才考虑并发。
Review the implementation for correctness and edge cases: error
handling, boundary conditions, and concurrency if this code path
can run in parallel. Flag anything risky.

Step 6 — 补测试
Follow the existing unit test patterns and add tests for the new
feature, covering the main path and key edge cases.

Step 7 — 验证跑通
写完不等于做完——跑起来验证,把测试和相关路径实际跑一遍。
Run the tests and the relevant code path to verify it works. Fix any failures.

7. 零代码起步：20 分钟用 AI 写一个 Full Stack App
说实话这个有点难，因为你完全不知道面试官想看什么——是想看 incremental progress，还是希望 AI 一把抓？20 分钟做 incremental progress (像上题那样) 太紧张了，所以我这里只能「一把抓」，流程类似上面：

• 先把 plan 列出来；
• 甚至可以先写一个粗略的 CLAUDE.md，把 dataclass、API endpoint、frontend pages 都定义清楚；
• 然后让 AI 生成，还是可以分步成db schema, API endpoint, then frontend pages
• 最后再加优化和 backend unit tests。

血泪 tip：如果你用工作电脑面试，切记先关掉你的 local dev server——8000 port conflict 现场很无语

. check 1point3acres for more.8. 零代码起步：用 AI 构建一个 AI Agent
这类题主要考流程设计和 DB schema 设计。interviewer 更关心你的初始设计，并且会在细节上 dive deep。
做题要点：

• 和 interviewer 沟通哪些部分可以 mock (LLM / API / data)
• 自己写 dataclass schema (这部分别交给 AI，这是主要考点本身)
• 结尾加 unit test 或一个 simple evaluation system

Question:

Build a simple AI agent that reads a pdf file uploaded by the user and then responses the summary

和面试官交流，自己手写主要entities
from enum import Enum
from dataclasses import dataclass, field
from uuid import uuid4

class RequestStatus(Enum):
    NEW = "new"
    IN_PROGRESS = "in_progress"
    SUBMITTED = "submitted"
    PROCESSED = "processed"
    FAILED = "failed"

class EventType(Enum):
    REQUEST_CREATE = "request_create"
    DOC_UPDATE = "doc_update"
    REQUEST_SUBMIT = "request_submit"

@dataclass
class Doc:
    """A file; hash enables dedup across requests."""
    id: str
    path: str
    hash: str
    created_at: str

@dataclass
class RequestDoc:
    """Many-to-many: one doc can belong to multiple requests."""
    request_id: str
    doc_id: str

@dataclass
class Request:
    """An auditor's question directed to a client."""
    id: str            # ★补上主键
    from_user_id: str
    to_user_id: str
    question: str
    status: RequestStatus
    tenant_id: str     # ★tenant贯穿
    created_at: str

@dataclass
class Event:
    """Event-driven state transition; idempotency_key prevents dup processing."""
    event_id: str
    request_id: str
    type: EventType
    status: RequestStatus
    payload: dict
    idempotency_key: str   # UNIQUE: f"{request_id}:{type}:{payload_hash}"
    created_at: str

@dataclass
class Output:
    """Answer with provenance (page/line/snippet/confidence) for citation."""
    id: str
    request_id: str
    doc_id: str
    page: int
    line: int
    snippet: str       # ★定一个类型(TEXT)
    confidence: float
    tenant_id: str
    created_at: str
几个设计点值得在面试里主动讲：Event.idempotency_key 加 UNIQUE 约束防重复处理；Output 带 page / line / snippet / confidence 是为了可溯源（citation / grounding）；tenant_id 贯穿始终做租户隔离。RequestDoc多对多: 一个doc可属多个request

AI PromptGoal: build an in-memory, event-driven AI agent system.
Use the dataclasses I've already defined above. Implement the logic on top of them.

[paste the hand-written dataclasses here]

Flow: an Auditor creates a Request to a Client, the Client uploads
PDF docs, and once submitted, an AI agent reads the docs and produces
a summary answer.
Implement this component (using the dataclasses above):

class EventBus:
    def emit(self, event: Event) -> None:
        """Dedup by event.idempotency_key, store, dispatch to handlers."""

    def register(self, event_type: EventType, handler: Callable) -> None:
        """Subscribe a handler to an event type."""

    def process_request(self, request_id: str) -> list[Output]:
        """On REQUEST_SUBMIT: gather docs, run agent, save Outputs, emit PROCESSED."""

Steps:
1. Auditor creates a Request → emit an Event(type=REQUEST_CREATE).
2. In emit(): dedup by idempotency_key (skip if seen), store, dispatch.
3. Client uploads a PDF → emit Event(type=DOC_UPDATE). Mock the file
   in memory (no real S3).
4. Auditor submits → emit Event(type=REQUEST_SUBMIT) → process_request.
5. Agent pipeline: gather Docs for the request → extract text (mock)
   → LLM answers question (mock) → guardrail → build Output objects
   (with page/line/snippet/confidence).
6. Store the Outputs.

Constraints:
1. Under 200 lines
2. One-line docstring per function
4. Mock the LLM and file I/O
5. Don't add tests yet

ReAct 还是 Multi-step Workflow?

主流程(create → upload → submit → process)用 Multi-step workflow(Temporal DAG), 因为 predictable + audit-friendly; ReAct 只用在探索性子任务(由 LLM 自己决定调哪些 tool)。

其他工程点(精简合并进 follow-up):
- Prompt caching: 稳定前缀缓存(如固定4096-token上下文)→ 省成本
- 容量估算: PDF ~600页(300k tokens ÷ 500/页) → 判断要不要切分/分批
- Multi-iteration: agent循环设上限(防失控)
- 幂等/去重: idempotency_key(事件) + doc hash(文件) → 生产也用

四、coding轮的小结与感受

LeetCode 可能会淡出主流
现在我估计 90%+ 的公司日常都在用 AI coding吧，那纯背题的意义就不大了，而且面试内容和现实脱节太多。说实话，现在除了要面试的人，还有多少人在手搓代码？
除了一些 startup 想显示自己很聪明，或者申请人太多需要用难题筛人，其他场景真的没必要。
相对地，code review、debug、大 codebase 加新功能这些内容会越来越多——它们考的是工程经验，这是 AI 替代不了、也是真正区分资历的东西。

一个实用建议：离职前把 GitHub commits 数量截图存下来。很多面试的公司会看，而你一旦离职、因为前司private repo可能关了，或者公司倒闭，这个数据就再也拿不到了。

现阶段，面试双方其实都很难

面试公司的困境

• 海量申请，还有 AI bot 批量投递，每份 resume 都被 AI polish 得很 fancy——已经不是人力可以 handle 的量级了。
• AI cheating：这里说的不是 OA 作弊，而是面试者本身就是 AI，不是真人。有个大公司的 HR 说他们遇到的候选人里 25% 是 AI fake person。好几家公司现在第一轮要视频验证 driver license，哈哈。而这成了一些公司的idea，他们会要求你录屏做一些initial interview or self introduction. 我感觉慢慢会正规化。
• 他们其实知道现在没人想刷 LeetCode 了，但出于惯性和筛人的刚需，还是在用。
• 最理想的方式当然是 work trial，但对公司来说成本太高，一般只有小公司会在最后一轮做。

求职者的困境

• LeetCode 这种东西一生刷一次就够了，那些烧脑的技巧工作中根本用不到。现在又有了 AI，刷题更显得反人类。
• 我更喜欢 PR review / code debug / practical problem。当然有些公司的 practical problem 其实是套壳 LeetCode，那就没意思了。真正的 practical problem，面完通常能学到东西。
• 而 LeetCode 面完你很难学到什么；大多数时候面完，面试官和求职者心里互相骂对方傻X，哈哈。

下一篇讲System Design. System design我个人还是比较喜欢，也一般做得不错（当然也挂过）。主要是不管做得好坏，做完之后和 AI 复盘都能学到不少, 这一点比 LeetCode 好太多了。

补充内容 (2026-09-08 02:38 +08:00):
下一篇在 https://www.1point3acres.com/bbs/thread-1188558-1-1.html

AI fake person。这事只有烙印能干出来。 估计把自己整成ai 短剧里的男主， 也不看看自己真长什么德行

楼主不是行业冥灯，楼主是我们找工人的灯塔啊

匿名用户 发表于 2026-09-05 15:23:04
离职前把 GitHub commits 数量截图存下来。很多面试的公司会看，而你一旦离职、因为前司private repo可能关了，或者公司倒闭，这个数据就再也

他们不能，但是可以看到多少commits in last year.
多少commits in private respositories.
您可以用Chrome incognito 看一下你的github profile

谢谢分享

谢谢分享，👍🏻

很感谢楼主的分享！感觉现在求职很考基本功啊

离职前把 GitHub commits 数量截图存下来。很多面试的公司会看，而你一旦离职、因为前司private repo可能关了，或者公司倒闭，这个数据就再也拿不到了。

楼主这个面试的公司怎么看啊，面试的公司为什么能access到离职公司的github

匿名用户 发表于 2026-9-5 15:23
离职前把 GitHub commits 数量截图存下来。很多面试的公司会看，而你一旦离职、因为前司private repo可能关 ...

从来没有听说过 请问是哪些公司看这些？

匿名用户 发表于 2026-09-07 18:34:05
从来没有听说过 请问是哪些公司看这些？

不少startup啊，申请的时候需要填github profile link。面试的时候有时候也说看过commit history，或者会问问相关的side project。当然大厂不会care这些。