Robinhood · Primly 社区

Robinhood security engineer 面试:整个 loop 里他们到底考了什么

sec_sasha (Primly starter) · 5 条回复

最近面了他们的 security engineering loop,岗位是 AppSec。这个流程和标准 SWE loop 有点不一样,所以值得单独写一篇。

Robinhood 的 security 这几年扩张了很多,可能也和几年前的一些公开事故有关。他们有 AppSec、cloud security、以及 detection/response 团队,不同 track 的面试流程会有些差异。我走的是 AppSec,所以我只讲这条线。

结构: Recruiter Screen(30 分钟,主要聊文化和岗位期望) 和 security engineer 的 Technical phone screen(45 分钟) Virtual onsite:4 轮

Phone screen 是混合型的。先从 threat modeling 开始:给了我一个 fintech 功能的简短描述(有点像 P2P 支付流程),让我过一遍可能的威胁。不是白板,就是口头讲。他们也问了常见 web 漏洞、类似 OWASP top 10 的东西,但不是那种打勾式问法,更像是“describe a time you found an injection vuln in production and what the blast radius was.(描述一次你在生产环境发现 injection 漏洞的经历,以及影响范围有多大。)”

Onsite 轮次: Secure code review: 给了一段代码(Python,偏真实的 fintech 业务逻辑,不是玩具题),让我找漏洞。我找到了不安全反序列化和支付处理里的 race condition。漏掉了一个比较隐蔽的 SSRF。他们不是靠坑你来打分,主要看你怎么推理。 带安全视角的 system design: 设计一个适用于 Robinhood 这个规模公司的 secrets management system。不只是基础设施设计,他们要你把 threat modeling 融进去。什么会失败,怎么失败,你的攻击者是谁。 Behavioral / leadership: 标准 STAR。他们很强调跨团队影响力:你怎么让一个 product team 真正去修一个他们已经降级优先级的漏洞。这个在 AppSec 里是真实难题,他们也很清楚。 和一个 senior eng 的 craft interview: 深挖我之前做过的一个 AppSec 项目。需要带自己的材料,我带着他们过了一次 pen test engagement。问题会问得很具体。

关键点: 深度胜过广度。他们一眼就能看出来你是不是在靠“我知道 OWASP”这种模式匹配,但其实没交付过任何东西。secure code review 那轮会直接把你暴露出来。

Comp:我没接,但给的 offer 是 senior 级别 AppSec,NYC,$190k base,外加 4 年 vest 的 RSU。对这个岗位来说算合理,但在 fintech 的 security 里不算顶级行情。

有问题欢迎问我。

由 AI 翻译,查看原文

5 条回复

infra_ines (Primly starter)

secrets management 的 design 题挺有意思。他们更在意架构还是 threat model?我见过这题不同问法,有的面试官想听 HashiCorp Vault,有的想让你自己发明一套 rotation 策略。

由 AI 翻译,查看原文

sec_sasha (Primly starter)

绝对更偏 threat model,而不是具体工具。我一开始很早就跳到 Vault,他们还稍微 push back 了一下,不是说它不对,而是他们想先听我在点名工具前,怎么推理哪些性质最重要:key rotation、audit logging、least-privilege access patterns。工具是后面的事。

由 AI 翻译,查看原文

mobile_mara (Primly starter)

「how do you get a product team to fix a deprioritized vuln(你怎么让一个被降优先级的漏洞重新被 product team 修复)」这个问题真的很难答好。很好奇你是怎么组织思路的。

由 AI 翻译,查看原文

sec_sasha (Primly starter)

我可以展开说说。基本是:我用 PM 关心的语言来讲怎么建立风险论证,能的话就把它挂到监管或合规的钩子上(fintech 这种很多),并且把紧迫性框成业务风险,而不是「可能会出坏事」。我也提到要让工程团队更容易修,而不只是让我更容易上报。他们好像挺吃这一套。

由 AI 翻译,查看原文

director_dee (Primly starter)

你描述的这种 behavioral 侧重,用在这种公司的 AppSec 岗很合理。技术门槛重要,但他们可能也见过那种只会搞安全、却没法跨团队沟通的纯安全 nerd,反而是负资产。security 里「influencing-without-authority」这件事比几乎任何岗位都更真实。

由 AI 翻译,查看原文