In a Beyond Coding interview, Nebius CTO Danila Shtan gives two answers that sound contradictory until you separate the roles. He says engineers who can build and operate GPU infrastructure are unusually valuable. Later he says memorizing a particular framework is less important than judging a product and its operating system as a whole. The distinction is between deep expertise where the physics and scale are hard and narrow implementation work without ownership of the result.
For Nebius, the strongest candidates can reason about infrastructure, performance or a product beyond the next coding ticket. Agents can accelerate implementation and incident investigation, but the engineer still has to challenge the output, explain the decisions and own production behavior. Danila's hiring and job-market forecasts are his perspective, not a universal map of every employer.
Watch the Full Interview
Credit: Danila's remarks come from the Beyond Coding interview and supplied transcript. Nebius's published interview guide and engineering page provide separate context; they do not validate every hiring or market estimate in the conversation.
The Skills He Calls Scarce
Infrastructure that keeps large workloads running
Danila starts with distributed-systems engineers who understand responsibility at scale. He then names low-level hardware and driver debugging, high-throughput storage and networking, and the ability to bring new GPU generations into production for customers (04:12). This tracks with Nebius's public engineering challenges, which include GPU fleet reliability, cluster troubleshooting, networking, Kubernetes and observability. It does not mean every company can or should hire the same profile.
GPU kernels and inference performance
He places particular value on people who can write kernels and reason about model execution at the GPU level as demand shifts toward inference. He estimates that the top cohort has only “hundreds” of people worldwide (04:12). Treat that as a CTO's estimate of an elite specialization, not a verified global count or salary survey. The practical point is that optimizing a real workload across hardware, memory, networking and serving behavior is harder to replace with a prompt than producing another ordinary interface.
The phrase “hard skills no longer matter” appears later in the interview, but it needs this context. Danila is arguing against treating one library or framework as the entire value of a generalist engineer. He is not saying GPU kernels, systems fundamentals or operational knowledge have become irrelevant. Nebius's interview guide still asks for algorithms, data structures and specialization-specific problem solving.
How Nebius Tests More Than a Résumé
Danila describes coding sessions, specialist rounds where relevant, and a three-month engineering bootcamp in which many hires rotate through teams before settling on one (08:12). The public guide confirms that core-cloud engineers can rotate across up to four teams, contribute to production work and choose a fit with feedback. It also confirms that the format varies by role; a low-level GPU specialist may not get the same distributed-system-design assessment as a general infrastructure candidate.
For senior engineers, Danila values a free-form project discussion: who chose the work, what users needed, which alternatives were considered, what happened in production and what feedback changed the direction (40:28). Nebius now calls a version of this a 90-minute Technical Deep Dive. Its guide asks candidates to explain their individual contribution and decisions, not merely display a polished team outcome.
Algorithms remain in the process because Danila sees them as a baseline for structured reasoning, not a contest to memorize a named trick (54:40). Nebius's guide makes the same distinction while advising candidates to practice core data structures and explain trade-offs. It also says AI and other answer-generating assistance are not allowed in interviews unless the stage explicitly permits it. Danila mentions a possible future agent-coding exercise; the interview says it is not yet part of the process (10:51).
His Agent Policy Is About Auditability, Not a Blanket Ban
The sharpest headline in the interview is that Danila will not grant widespread Claude Code access. The full answer matters: Nebius engineers do have access to OpenAI models and Codex, and can build agent workflows. He says he wants stronger guardrails and observability before wider Claude Code rollout, because enthusiasm for a hyped tool is not itself a use case (36:57). That is a local engineering policy described by its CTO, not evidence that Claude Code is inherently unsuitable for production teams.
His proposed production-merge rule is unusually concrete: identify whether a pull request was agent-assisted and retain the session trajectory that produced it, so reviewers can inspect the decisions and challenges that shaped the change (37:46). The interview presents this as a standard he wants tooling to support; it does not establish that every Nebius repository already enforces it. A session record can aid review, but it must also respect credentials, customer data, retention rules and access controls.
Danila likens an agent to a junior engineer: useful, fast and sometimes surprisingly capable, but missing context and prone to following a flawed premise too far (35:32). One failure mode is letting the same agent create both implementation and tests, then treating green tests as independent proof. His better examples are bounded: collect logs and metrics during an incident, suggest mitigations, or cross-check a human-written postmortem against available evidence (52:26). These remain interview examples, not measured before-and-after studies.
What the Engineer Still Has to Own
Danila rejects the promise that agents will autonomously handle the entire engineering loop at his company's scale (28:17). He is not rejecting agentic work: he says it helps him turn ideas into prototypes quickly. His objection is to replacing accountability with generated code. Someone must still decide whether the problem is worth solving, what evidence would disprove the agent's answer, what happens when the system fails and who is on call.
That wider view is what he calls a move from a T-shaped to a more “round-shaped” engineer: enough awareness of implementation, architecture, operations, users and product decisions to notice when the local task is wrong (42:32). It does not require every junior engineer to master all those fields at once. His account of Nebius's rotational onboarding and its early-talent program points to ways to build that context through real work.
His prediction that narrowly task-driven developers at large banks may disappear within three to five years is the most speculative part of the conversation (47:11). It is an opinion about one kind of organizational role, not a forecast that Java or bank engineering vanishes. He also concedes that institutional knowledge and undocumented systems complicate any replacement. A reader should use the warning to broaden ownership and improve documentation, not treat it as a countdown on a whole profession.
A Practical Career Test
Use the interview as a way to audit the proof you can show, not as an instruction to chase whichever GPU keyword is popular this month:
- Show depth where your work is real. Pick a system you have actually built or operated. Explain one bottleneck, how you measured it, the trade-off you chose and what changed. A kernel benchmark is valuable only if the workload and measurement are honest.
- Show the whole decision. Prepare the project story Nebius asks for: user or customer need, your contribution, alternatives, production behavior, failure, feedback and the next revision. Separate your work from the team's.
- Show independent judgment with agents. Keep an example where an agent's proposed solution or test was wrong. Describe the outside evidence you used to catch it and what you changed before merge.
- Prepare for the actual interview rules. If applying to Nebius, read the current role-specific guide and openings. Practice fundamentals without AI assistance for the interview itself unless the recruiter explicitly authorizes it.
Jump to a Segment
| Time | Topic |
|---|---|
| 00:00 | The limit of autonomous-agent promises |
| 00:44 | What Nebius builds |
| 04:12 | Scarce infrastructure and GPU skills |
| 06:58 | Hiring and specialist rounds |
| 08:12 | Three-month engineering bootcamp |
| 10:51 | No AI in current interviews |
| 16:31 | Why he avoids “headcount” |
| 22:25 | The CTO's management role |
| 24:49 | Managing expectations |
| 25:48 | Why communication fails |
| 28:17 | The limits of autonomous engineering |
| 31:39 | Agents multiply the engineer's baseline |
| 35:32 | Working with an agent like a junior |
| 36:57 | Why Claude Code access is limited |
| 37:46 | The proposed agent-code audit trail |
| 40:28 | Project deep-dive interview |
| 42:32 | From T-shaped to round-shaped |
| 44:30 | A path for junior engineers |
| 45:28 | Framework fluency versus fundamentals |
| 47:11 | His at-risk-role prediction |
| 50:04 | Why stable jobs still appeal |
| 52:26 | Agents in incident response |
| 54:40 | Why algorithms remain in interviews |
| 56:05 | Technical curiosity and engineering |
Sources and Limits
Interview: Beyond Coding with Danila Shtan and the user-supplied transcript. Company context: Nebius engineering, published interview process and AI-use rule, early-talent program and live openings, checked 20 October 2026. “Hundreds” of elite GPU specialists, the timeline for at-risk roles and the productivity of incident agents are Danila's estimates or experiences; no independent labor census or controlled performance study accompanies this interview. Policies, roles and openings can change.