Etched is a strange interview target because the company is betting everything on one architectural decision. Sohu is an ASIC that runs transformers and nothing else. No convolutions, no arbitrary graphs, no hedging. That single bet is fabricated on TSMC’s 4nm process with 144GB of HBM3 per chip, and the company’s public pitch is roughly an order of magnitude more inference throughput than an equivalent Nvidia part on transformer workloads. Whether or not that number holds in your workload, it tells you exactly what they screen for: people who understand why fixing the architecture in silicon is a real advantage and where it becomes a trap.
The company exited stealth on June 30, 2026, and, per press reports from around that time, had raised somewhere near $800M with more than $1B in signed customer contracts. Reporting since then put total funding past a billion and the valuation into the ten-billion-plus range, though specific valuation figures differ meaningfully between outlets, so don’t anchor on any single number. The headcount is still small for that valuation, a few hundred people, and a chunk of the senior silicon bench was hired out of Nvidia, Broadcom, and the old Cypress semiconductor world. That matters for your prep: your interviewers have taped out real chips and shipped real compilers. They can tell the difference between someone who has read about a topic and someone who has debugged it at 2am before a tapeout deadline.
The three role families, and why they screen differently
Almost every open req at Etched falls into one of three buckets, and the interview loop bends heavily toward whichever one you’re applying for. Trying to be a generalist here works against you.
Silicon and RTL design
This is the core of the company. Expect questions on the actual mechanics of digital design: pipelining a datapath, clock domain crossing, resolving timing on a critical path, area-versus-power tradeoffs, and how you’d verify a block. If your resume says Verilog or SystemVerilog, someone will ask you to write or read it live. A realistic prompt: “You have a systolic array doing matrix multiply and you’re missing timing by 300ps on the accumulate path. Walk me through your options.” They want to hear retiming, pipeline stage insertion, and the cost each one imposes, not a hand-wave.
Compiler and kernels
A transformer ASIC lives or dies on its software stack. If the compiler can’t map a model onto the fixed-function attention and matmul units efficiently, the hardware advantage evaporates. This track leans on graph lowering, operator fusion, memory planning across a limited on-chip buffer, and the scheduling problem of keeping the compute units fed from HBM. Expect a question shaped like: “Given this attention subgraph and a fixed set of hardware primitives, how do you tile it so you’re not bottlenecked on memory bandwidth?” Strong candidates reason in bytes moved and arithmetic intensity, not just asymptotic complexity.
ML systems and infrastructure
This is the track closest to conventional software interviewing and the one where general engineers have a path in. It covers the inference serving stack, batching and KV-cache management, distributed execution across chips, benchmarking, and the numerical work of getting a model to run correctly in reduced precision. If you’ve worked on inference at Together AI or Fireworks AI, or on serverless GPU execution at Modal, that experience maps directly and you should lead with it.
Because this is billed as the way in for general engineers, it’s worth seeing how deep it actually goes. The questions are shaped by real serving constraints, not trivia:
- “Your KV cache is filling up under load. Walk me through an eviction or paging strategy, and what you lose when a sequence’s cached keys get dropped.”
- “Compare continuous batching against static batching for a mixed workload of short and long prompts. Where does each waste compute, and which do you pick?”
- “You quantize a model to run in reduced precision on the chip and the outputs drift from the reference implementation. How do you localize the numerical skew between training and serving, and what do you fix first?”
- “You’re sharding a 400B-parameter model across multiple chips. How do you split it, and where does the interconnect become the bottleneck before compute does?”
- “Two models share one chip. How do you schedule them so a bursty request stream doesn’t starve the other model’s latency SLO?”
If you’re coming from application-side backend work and this feels unfamiliar, the fastest ramp is to build a working mental model of an open LLM serving stack (vLLM is the common reference: read how it does paged attention and continuous batching), then reason about how those same problems change when the target is a fixed-function chip instead of a GPU. The site’s system design interview guides hub covers the distributed-systems half of this; the inference-specific half you’ll mostly get from the serving-engine docs.
A realistic loop, with one caveat
No one has published a detailed Etched loop yet, so what follows is inferred from the role types and from how Groq, Cerebras, and SambaNova structure their hiring. Treat it as a planning tool, not gospel.
The front door is usually a recruiter call followed by a technical screen with a hiring engineer, 45 to 60 minutes, focused on your primary lane. For silicon that’s an RTL or architecture discussion; for compiler and infra it’s often a coding or design problem tied to real hardware constraints. The onsite (frequently virtual) is typically four to five rounds: a deep technical dive into your strongest area, a broader systems or architecture round, a hands-on coding or RTL exercise, and a conversation with a founder or senior lead that is equal parts technical judgment and “do you actually believe in the transformer-only bet.” At a company this small, culture-fit rounds carry real weight because a bad hire is a larger fraction of the team.
| Round | Who runs it | What they’re actually testing |
|---|---|---|
| Recruiter screen (30 min) | Recruiter | Track fit, motivation for hardware over cloud AI, logistics and comp expectations |
| Technical phone screen (45-60 min) | Hiring engineer | Depth in your primary lane: RTL, compiler internals, or inference systems |
| Domain deep-dive (60 min) | Senior engineer in your area | Can you debug and design at real production depth, not textbook level |
| Architecture / systems round (60 min) | Cross-functional engineer | How your work connects to the chip, the compiler, and the serving stack |
| Hands-on exercise (60 min) | Engineer | Live RTL, kernel, or coding problem under hardware constraints |
| Founder / lead conversation (45 min) | Founder or staff lead | Judgment, ownership, and genuine conviction in the transformer-only thesis |
Questions phrased the way they’re actually asked
These are representative of the domain, drawn from how hardware and ML-infra loops tend to probe, not leaked Etched questions:
- “Why does a transformer-only ASIC beat a GPU on inference, and where does that advantage break down?” (Everyone gets some version of this. The right answer names fixed-function attention, higher utilization, and less control overhead, then names the risk: architectures move, and silicon doesn’t.)
- “Estimate the HBM bandwidth you need to serve a 70B-parameter model at a given tokens-per-second target.” (A back-of-envelope roofline question. Show your arithmetic.)
- “You’re fusing softmax into the attention kernel. What breaks numerically, and how do you keep it stable?”
- “Design the verification plan for a new matmul unit. What’s your coverage strategy and where do you expect the bugs?”
Notice what’s missing: there’s very little classic algorithm-puzzle content. You should still be fluent with core coding patterns for the infra track’s coding round, but nobody here is asking you to invert a binary tree for its own sake. The signal they want is whether you reason about hardware, memory, and numerics under real constraints.
Compensation, described as a range
Etched hasn’t published comp bands, and I won’t invent specific numbers. What I can give you is calibration. As of 2026, senior silicon, compiler, and ML-infra offers at well-funded pre-IPO hardware startups commonly cluster with a cash base broadly comparable to senior big-tech roles, in the rough neighborhood of $180K to $260K depending on level and location. Treat that as a general market range, not Etched’s actual bands, and verify current data before you negotiate. The base is often a touch lower than the biggest public players; the pitch is equity upside, and that’s where the real variance lives. A specialist silicon or compiler hire with rare skills can negotiate meaningfully more ownership than a generalist.
Two things to verify before you sign. First, get the number of shares and the total shares outstanding, not just a dollar “value,” so you can compute your actual ownership and reason about dilution. Second, check current data on comparable companies and model a few outcomes with a total comp calculator rather than trusting the recruiter’s headline figure. For the mechanics of pushing back on an offer, the salary negotiation playbook applies here the same as anywhere, with the added lever that specialist hardware talent is genuinely scarce right now.
One more thing international candidates should settle early: sponsorship status at Etched is unconfirmed, and export-control rules on semiconductor and chip-design work can in practice restrict some roles to US persons in a way pure-software jobs rarely are. Ask the recruiter directly in the first call rather than finding out after four rounds.
How to prep without wasting your time
Pick your lane and go deep. A silicon candidate should be able to write clean SystemVerilog on a whiteboard, reason about timing and power, and describe a verification methodology they’ve actually used. A compiler candidate should be comfortable with graph IRs, tiling, and the arithmetic-intensity math behind memory-bound versus compute-bound kernels. An infra candidate should know the inference serving stack cold: batching, KV cache, quantization, and multi-device execution.
Across all three, have a crisp opinion on the central bet. When they ask why you want to work on a chip that only runs transformers, “the transformer won and specializing for it is worth the architectural risk” is a defensible answer. “I want to work on cool AI hardware” is not. This is a company built on conviction, and the interview is partly a test of whether you share it. If you’re weighing Etched against other AI-native employers, the broader AI company interview guides and the AI-startup interview difficulty index are worth a look to see where the hardware bet sits next to the model and application companies.
The riskiest thing about interviewing here isn’t the questions. It’s joining a company whose entire thesis depends on the transformer staying the dominant architecture for the life of a chip you help design. If you believe that, few places will give a silicon or systems engineer this much leverage per person. If you don’t, no comp package makes that bet comfortable, and the interviewers will notice the hesitation.
Practice the behavioral round:
