Brave

> I interviewed for a Release Engineer role at Brave Software and the experience was not what I expected. I went in prepared to talk about CI/CD architecture, Jenkins declarative versus scripted pipelines, TeamCity with Kotlin DSL, scaling Chromium builds, artifact promotion, reproducibility, and release orchestration at scale. Instead, the interview focused almost entirely on low-level Linux and networking fundamentals. They wanted exact df and tcpdump flags, not general debugging approaches but precise switches. The discussion moved into the TCP three-way handshake, congestion control under latency, reciting the OSI model in order, explaining how iperf works internally, how to build a VPN tunnel from scratch, kernel parameter tuning, and filesystem internals like inode mechanics. What stood out was what they did not ask. There were no questions about pipeline design, distributed runners, artifact lifecycle management, branching strategies, or optimizing large-scale Chromium builds. Nothing about LUCI, how canary releases are structured, or how GN generates Ninja build files. Those are systems directly relevant to a browser release workflow and stuff I've actually worked with. Instead, the evaluation felt like a screening for a low-level Linux systems engineer who lives in /proc, tunes sysctls manually, and debugs networking stacks from first principles. The issue was not technical depth. Deep systems knowledge is valuable. The issue was alignment. If the role is effectively “senior systems engineer” that should be explicit. When a position is labeled Release Engineer, most candidates will prepare to discuss build graphs, caching strategies, deterministic builds, artifact promotion models, and release safety mechanisms. Fast-fire trivia about command flags and OSI ordering, without discussion of process or systems design, does not evaluate how someone actually engineers reliable release pipelines. Besides, I have familarity with all of these tools, but I haven't been a sysadmin for 10 years, so remembering the IPTABLES flags to allow or reject rulesets is something I'd google and automate in Pulumi or Ansible or preferably just create an AWS security group or GCP firewall rule. Seems a bit odd to be using iptables as your first line of defense in 2026. In fact, I'd prefer to be creating builds for a browser in a private VPC with NAT gateways to publish them? It raises a broader question: why do some companies advertise one scope of work but interview for another? If the day-to-day work revolves around Chromium build infrastructure, LUCI orchestration, GN/Ninja workflows, and staged rollouts, then those should be central to the interview. Otherwise, candidates end up preparing for large-scale build engineering discussions and instead find themselves taking what feels like a Linux internals exam. The interviewer was the director and had previously held the role of release engineer, so confused by it! It did not help this guy was rapid firing questions, seemed very annoyed and detached and was very clear he felt he wast wasting his time, and came off combative at times during the discussion. For instance he challenged aggressively why I do not use brave as my browser and made me defend my position. It's a job, not a cult sir? I've tried it out, but I don't have to religiously use software just because I'm interviewing there. Anyone else interview here and find the process here to be a bit odd?