DoorDash Interactive Coding：城市范围内营业餐厅筛选

题意与假设

这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。

• 题目未公开类签名、range 的几何定义、营业时区或输出格式。示例将两个判断作为注入的权威谓词，保留输入顺序；不编造实际 starter 的方法名。
• 训练契约要求两个条件都为真才返回餐厅，任一 API 抛错则让调用方看到错误，避免在未确认产品策略前把“未知”当“营业”。
• 可见题面没有要求按距离排序或分页，示例只做筛选；若 mockup/服务接口另有输出 shape，应按现场要求调整。

解题路线

1. 先读 City/Restaurant 的公开方法、返回类型和示例对象，确认 API 是同步、异步、按餐厅查还是支持批量。把营业判断和范围判断分成两个独立条件，写 truth table 覆盖 4 种组合。
2. 用适配函数遍历餐厅，调用权威的 is_open 与 in_city_range；两者同时为真才追加。保留原输入顺序，使结果稳定；重复餐厅 ID 是否去重要问题面。
3. 性能追问先区分数据规模与 API 成本：如果 N 个餐厅且每次远程调用 2 次，逐个请求是 O(N) 次调用并可能受延迟累加；可按 city 批量取得候选，再并发限流地验证营业，给每路 deadline。
4. 若营业状态与范围数据会变，缓存只作候选加速，最终返回前按产品 freshness 目标复核；API 错误、超时和部分结果要有明确契约与指标。

手动走一遍

给定餐厅 A(营业且在范围)、B(营业但范围外)、C(范围内但打烊)、D(两者都否)，输出只有 A。示例代码使用传入谓词模拟封装类 API，不能据此推断真实面试的几何计算或字段名称。

Python 参考实现

下面的代码按上文假设实现，适合本地运行并追加自己的测试用例。

代码区可横向滚动；使用键盘时，先聚焦代码区再按方向键查看。

"""Training adapters for the visible DoorDash interactive API prompt."""

from collections.abc import Callable, Iterable
from typing import TypeVar


Restaurant = TypeVar("Restaurant")
City = TypeVar("City")


def eligible_restaurants(
    city: City,
    restaurants: Iterable[Restaurant],
    *,
    is_open: Callable[[Restaurant], bool],
    in_city_range: Callable[[City, Restaurant], bool],
) -> list[Restaurant]:
    """Preserve input order and apply both authoritative predicates."""
    result: list[Restaurant] = []
    for restaurant in restaurants:
        if is_open(restaurant) and in_city_range(city, restaurant):
            result.append(restaurant)
    return result

复杂度

本地遍历 N 个餐厅为 O(N) 时间、输出最多 O(N) 空间；远程 API 版本的主成本是 2N 次调用或批量调用数与尾延迟。若可以先按地理索引缩到 K≪N 个候选，再做开放状态检查，负载约与 K 成正比。

易错点与追问

容易失分的边界

• 把营业与城市范围用 OR 连接会把关店/范围外餐厅放出来；必须是 AND。
• “在同一 city”不一定等于“在 city range”：前者可能是行政区，后者可能是送达范围；题目只说封装 API 判断，不能自行替换成经纬度矩形。
• 忽略时区、临时停业、配送半径动态变化，会使缓存结果在生产中失真；这些是性能/可靠性追问，不是题目明确的编码字段。
• 并发调用不设上限可能压垮下游；批量与限流需要和 API 能力一致。

继续深挖

• 若 API 返回 unknown/timeout，先与产品确认 fail-closed、标记暂不可用还是返回部分结果；记录哪一判断失败以便恢复。
• 若餐厅太多，先通过城市/地理索引获取候选，再并发批量查营业；检查分页一致性与结果去重。