Algorithms Day 1 — #217 Contains Duplicate

💻 算法 Day 1 / Algorithms Day 1 — #217 Contains Duplicate (Easy) — Arrays & Hashing

现实类比 / Real-World Analogy

想象你在整理一箱名片。你从盒子里一张一张往外拿，每拿出一张，先看看桌上有没有一样的。如果有，说明你有重复的联系人。这就是「哈希集合」的工作方式——把「已见过的」放在一个快速查找的结构里。

Imagine going through a box of business cards. You pull each card out and check if you've already put one on the table. If you find a match, you have a duplicate. That's exactly what a hash set does — it gives you O(1) lookup for "have I seen this before?"

题目 / Problem Statement

给你一个整数数组 nums，如果其中存在任何重复值，返回 true；否则返回 false。

Given an integer array nums, return true if any value appears at least twice, false if every element is distinct.

逐步分析 / Step-by-Step Walkthrough

方法一：暴力法（别用这个）

双重循环，比较每对元素。Time: O(n²)，Space: O(1)

面试中绝对不要停在这里。

方法二：排序法

排序后相邻元素比较。Time: O(n log n)，Space: O(1)

稍好，但破坏了原数组顺序。

方法三：哈希集合（最优解）

维护一个「已见过」的集合，遍历一次搞定。

Python 解法 / Python Solution

def containsDuplicate(nums: list[int]) -> bool:
    # Use a hash set for O(1) average-case lookup
    seen = set()
    
    for num in nums:
        if num in seen:
            # Found a duplicate — return immediately (early exit)
            return True
        seen.add(num)
    
    # No duplicates found after full traversal
    return False

# One-liner alternative (Pythonic, but reads the whole list)
# return len(nums) != len(set(nums))

为什么用 set 而不是 list？

x in list → O(n)，要遍历找

x in set → O(1)，哈希直接定位

list membership check is O(n); set uses hashing for O(1) average lookup. This is the key insight.

复杂度 / Complexity

最优解是时间-空间的经典权衡：用 O(n) 额外空间换取 O(n) 时间。

Classic time-space tradeoff: we pay O(n) space to get O(n) time.

举一反三 / Pattern Recognition

这道题是「Arrays & Hashing」模式的入口。掌握它，你能解：

1. #1 Two Sum — 同样的「已见过」思路，存的是值→索引的映射
2. #128 Longest Consecutive Sequence — 先用 set 存所有数，再按规律遍历
3. #49 Group Anagrams — 用排序后的字符串作 key，用 dict 分组
4. #36 Valid Sudoku — 三个方向各维护一个 set

核心模式：每次遇到「需要快速判断某元素是否出现过」，第一反应是 set；需要记录「出现次数或位置」，用 dict。

The pattern: whenever you need "have I seen this before?", think set. When you need "how many times / where did I see it?", think dict. This pattern appears in ~30% of easy/medium array problems.

Mini Challenge 🎯

如果题目改成：找到数组中出现超过 n/2 次的元素（保证存在），怎么做？

What if you need to find the element that appears more than n/2 times? (Boyer-Moore Voting Algorithm — hint for tomorrow's pattern thinking)

Soft Skills Day 1 — Decision Making Under Uncertainty

🗣️ 软技能 Day 1 / Soft Skills Day 1

在信息不完整时做出关键技术决策

Making Critical Technical Decisions with Incomplete Information

为什么这很重要 / Why This Matters

初级工程师等信息齐全再行动。高级工程师知道：信息永远不会完全齐全。

系统随时会挂，竞争对手随时会发布，产品上线时间表不会等你做完全量分析。Senior/Staff 工程师和 L3 工程师最大的差距，不是编码能力，而是在模糊中决断的能力。

Junior engineers wait for complete information. Senior engineers know it never arrives. The gap between L3 and Staff isn't coding — it's the ability to make good decisions under uncertainty and own the outcome.

STAR 框架拆解 / STAR Framework

Situation（情境）

描述背景，但要聚焦：有什么压力？为什么信息不完整？

⚠️ 不要花超过 20% 的时间在这里

Task（任务）

你需要做什么决定？有什么约束？时间线？

清楚说明为什么这个决定很难。

Action（行动） ← 这是重点，占 60-70%

• 你如何快速收集最关键的信息？
• 你评估了哪些方案？
• 你如何在时间压力下做出判断？
• 谁参与了决策，如何达成共识？
• 你如何记录决定和理由（ADR）？

Result（结果）

具体指标。但如果结果不完美，更要说清楚你学到了什么。

❌ 糟糕的回答 / Bad Approach

"我们的数据库响应变慢了，我研究了一下，最后升级了实例类型，问题解决了。"

问题出在哪里：

• 没有体现「信息不完整」的挑战
• 没有说明评估过的其他方案
• 没有数字
• 听起来是一个人默默解决，没有体现协作
• 面试官不知道你的思维过程

✅ 好的回答结构 / Good Approach

"2024年Q3，我们的支付服务在高峰期 p99 延迟从 80ms 跳到了 800ms，但我们不知道根因——可能是代码、数据库、还是下游 API。问题是周五下午5点发生的，我们有个重要的 launch 在下周一。"

"我需要在没有完整 tracing 数据的情况下（我们当时监控覆盖率只有60%）决定：是回滚最近的部署、扩容数据库、还是限流？"

"我做了三件事：第一，让团队15分钟内各自排查一个方向，并行收集证据。第二，设定了一个阈值——如果30分钟内找不到根因，就先限流保护系统，再继续排查。第三，在 Slack 里实时记录我们的假设和证据，方便团队同步。"

"结果是我们在22分钟内发现是一个 N+1 查询问题被一次数据迁移触发了。我们加了一个临时索引，延迟降到了 95ms，顺利支撑了周一 launch。事后我们补了完整的 APM tracing。"

场景模板 / Scenario Template

背景: [系统 X] 在 [时间点] 出现了 [问题/机会]
信息缺口: 我们不知道 [关键未知项]，因为 [原因]
约束: [时间/资源/风险约束]
我的决策框架:
  - 快速信息收集: [做了什么]
  - 方案评估: [A vs B vs C，为什么选A]
  - 风险缓解: [如何降低决策风险]
  - 沟通对齐: [如何同步团队/stakeholders]
结果: [具体数字] + [事后学到的]

Senior/Staff 加分项 / Level-Up Tips

1. 提到 ADR（架构决策记录）

"我们写了一个 ADR 记录了这个决定和我们当时的信息状态，方便3个月后的人理解为什么这么做。"

1. 主动承认决定的局限性

Staff 级别的工程师不假装自己的决定完美，他们说："这是基于当时信息的最优解，我们设置了一个检查点在30天后重新评估。"

1. 体现系统性思维

不只解决这次的问题，还要防止下次同类问题发生。

关键要点 / Key Takeaways

• 面试官想看的是你的思维过程，不只是结果
• 信息不完整≠瘫痪，要展示你如何快速收集关键信息
• 好的决定有明确的理由，坏的结果有清晰的复盘
• 量化一切：延迟数字、时间窗口、影响用户数

The interviewer wants to see: structured thinking under pressure, ability to make good-enough decisions fast, and ownership of outcomes regardless of result.

Frontend Day 1 — CSS Box Model: The Foundation of Layout

🎨 前端 Day 1 / Frontend Day 1

CSS 盒模型 — 所有布局的起点

CSS Box Model — The Foundation of Layout

猜猜这段代码输出什么？/ What does this code output?

.box{
  width: 100px;
  padding: 20px;
  border: 5px solid black;
  margin: 10px;
}

<div class="box">Hello</div>

问题：.box 在页面上占多少宽度？

Question: How wide does .box actually appear on screen?

A) 100px

B) 150px

C) 160px

D) 170px

答案是 C) 160px — 但等等，很多人会猜 A！

Most people guess A. The answer is C — here's why.

盒模型可视化 / Box Model Visualization

默认的 box-sizing: content-box 意味着 width 只是内容区域的宽度。

Padding 和 border 会叠加在外面，让元素比你想的更大。

解决方案：box-sizing: border-box

/* 现代 CSS 的最佳实践 / Modern CSS best practice */
*, *::before, *::after {
  box-sizing: border-box;
}

.box{
  width: 100px;   /* Now this IS the final rendered width */
  padding: 20px;
  border: 5px solid black;
  /* Content area auto-shrinks to: 100 - 40 - 10 = 50px */
}

用了 border-box 后，width: 100px 就真的是 100px，padding 和 border 都"向内压缩"。这是几乎所有现代 CSS 框架（Bootstrap、Tailwind）默认使用的设置。

With border-box, width means what you think it means. Padding and border carve inward. This is why every modern CSS framework resets box-sizing globally.

你可能不知道 / You Might Not Know

Gotcha #1: margin 不是元素的一部分

margin 是元素与其他元素之间的空白，不影响元素本身的宽度，但影响布局空间。用 background-color 你会发现 background 不延伸到 margin 里。

Gotcha #2: Margin Collapse（外边距折叠）

.top    { margin-bottom: 20px; }
.bottom { margin-top: 30px; }

两个块级元素垂直相邻，你以为间距是 50px，实际是 30px（取较大值）。

水平方向的 margin 不会折叠，只有垂直方向才有这个"惊喜"。

Vertical margins between block elements collapse to the larger value. Horizontal margins never collapse. This trips up every developer at least once.

Gotcha #3: inline 元素的 padding/margin 行为不同

<span> 这类行内元素，设置 padding-top/bottom 和 margin-top/bottom 不会影响行高，效果跟你想的不一样。要控制高度，先把它变成 inline-block。

Mini Challenge 🎯

不用打开浏览器，算出这个元素的实际渲染宽度：

.card{
  box-sizing: border-box;
  width: 300px;
  padding: 16px;
  border: 2px solid #eee;
  margin: 24px auto;
}

渲染宽度是多少？内容区域宽度是多少？

What's the rendered width? What's the content area width?

答案下方揭晓：

• 渲染宽度：300px（因为 border-box）
• 内容区域：300 - 32 - 4 = 264px

AI Day 1 — AI News Roundup

Date: 2026-03-14 | Mode: NEWS

🤖 AI Day 1 — 本周 AI 大事件 / This Week in AI

📰 Story 1: Claude 1M Context 全面开放

Claude's 1M Token Context Window Goes Generally Available

Anthropic 昨天（3月13日）宣布，Claude Opus 4.6 和 Sonnet 4.6 的 100万 token 上下文窗口正式 GA，并且不收长上下文溢价——无论你发送 9K 还是 900K token，每 token 定价相同（Opus: $5/$25/M，Sonnet: $3/$15/M）。同时单次请求可以包含最多 600 张图片或 PDF 页面（之前是 100）。

Anthropic made the 1M context window for Claude Opus 4.6 & Sonnet 4.6 generally available on March 13 with no long-context premium. Same per-token price whether you send 9K or 900K tokens. Media limits expanded 6x to 600 images/PDFs per request.

为什么你应该关心 / Why You Should Care:

对于需要处理整个代码库、大型合同文档、或长时间 agent 运行的工程师来说，这是实质性突破。之前 200K 以上需要特殊 beta header，现在自动生效。Claude Code 的 Max/Team/Enterprise 用户也自动获得 1M 上下文，减少 compaction 中断——Anthropic 表示这让 compaction 事件减少了 15%。

For engineers working with large codebases, legal documents, or long-running agents: this eliminates forced context compression. A 1M context means you can load an entire enterprise codebase and reason across it without losing track of earlier decisions.

📰 Story 2: 「会思考的 AI」正在改变代码审查

AI Agents Are Changing Code Review

越来越多的团队开始用 AI agent（Claude Code、Devin、Copilot Workspace）做第一轮代码审查。一个真实案例：某公司把整个 diff 喂给 Opus 4.6 的 1M 上下文，拿到比分块处理高质量得多的跨文件依赖分析。

Teams are deploying AI agents as first-pass code reviewers. With 1M context, agents can ingest full diffs and reason about cross-file dependencies that chunking strategies miss.

为什么你应该关心 / Why You Should Care:

这不是说 AI 要取代 code review，而是说 AI 能处理「检查你有没有更新所有调用者」、「这个改动和3个文件之外的逻辑一致吗」这类枯燥但重要的检查，让人类 reviewer 聚焦在架构和意图层面。

AI handles the mechanical review (did you update all callers? is this consistent with the contract 3 files away?). Humans focus on intent and architecture. Your job as a reviewer is evolving.

📰 Story 3: 多模态 AI 的「看懂图纸」能力

Multimodal AI Learning to Read Engineering Diagrams

前沿模型处理架构图、电路图、数学公式的能力在过去一年显著提升。工程师们开始用它来：解读遗留系统的手绘架构图、分析竞争对手产品的硬件拆解照片、把 Figma 截图直接转成 React 组件。

Frontier models have dramatically improved at reading architecture diagrams, circuit schematics, and hand-drawn flowcharts. Engineers are using this to digitize legacy documentation and convert design screenshots to code.

为什么你应该关心 / Why You Should Care:

如果你的团队还有一堆「只有某个老员工看得懂」的架构图、Confluence 里的白板照片，现在是时候让 AI 把这些知识结构化了。技术债不只是代码债，文档债也是。

The "tribal knowledge" locked in whiteboard photos and napkin sketches can now be extracted. Teams that act on this will onboard engineers faster and reduce key-person risk.

📰 Story 4: Vibe Coding 的隐藏成本

The Hidden Costs of Vibe Coding

「Vibe coding」（完全让 AI 写代码，自己不看细节）在 Twitter/X 上很流行，但越来越多的工程师报告了真实代价：安全漏洞（AI 生成了但没人审查）、架构债（快速生成的代码结构混乱）、以及最麻烦的——你不理解自己系统的工作原理，无法 debug。

"Vibe coding" — prompting AI to build entire features without reviewing the output — is creating a new class of tech debt: security vulnerabilities nobody audited, architectural chaos from unreviewed code, and engineers who can't debug systems they nominally wrote.

为什么你应该关心 / Why You Should Care:

AI 是加速器，不是替代品。最有效的工程师是「AI 辅助」而不是「AI 依赖」。理解你代码中每一个关键决策，即使是 AI 建议的，是职业生涯的护城河。

The engineers who thrive long-term use AI as an accelerator, not a replacement for understanding. Owning your code means being able to explain every key decision — even if AI suggested it.

本周一句话总结 / One-Line Summary

上下文窗口越来越大，AI 能「记住」的越来越多——但你需要理解的也越来越多。工具在进化，思维方式也得跟上。

Context windows are expanding, AI can remember more — but so does your responsibility to understand what it's doing. The tools are evolving; so must the mindset.