AI Cloud CTO: Which Engineering Skills Are Most In-Demand Right Now

Speaker A: I think the promise of agents will do everything is bullshit.

Speaker B: This is Danila Stan, CTO of Nebius, one of the biggest AI cloud providers.

Speaker A: You can't imagine how hard it is to be one of the first to adopt new Nvidia chips in production for a large customer. Working with an AI agent is not dissimilar to working with a junior engineer. People want cloud code not because they want an agent to work for them, they want clerk code because it's a hyped tool and everyone's talking about that.

Speaker B: Can people use agentic tooling within the hiring process?

Speaker A: No. Very task oriented, very mechanical. This is a cohort of engineers that are at risk right now.

Speaker B: For the people that don't know. What does Nebius do?

Speaker A: Nebivous, uh, is a cloud company, uh, but uh, because we've started pretty late in the game so like just for the scale, four years ago there was no nibirs. Three and a half years ago there was an idea that we know what to build and it turned out something completely different. The current shape of being the AI oriented cloud, so mainly focused on GPUs, AI workloads, et cetera, and came up about like two, two and a half years ago. So we were late to the game for the cloud stuff and we had to find a niche and ChatGPT was released, Llama was released, everything started moving to the direction that we see it now and we uh, decided, well, this might be something we can be successful and we built that. So we are the AI cloud. The cloud, but like uh, mainly focused on AI centric workloads, mainly enabled by GPUs and having access to an enormous amount of GPUs is one of our main assets that we build upon.

Speaker B: It's interesting that you said you're kind of late to the game and it could be my ignorance, but doing my research, I thought you were a little bit early. Like who are people that were earlier in the space or companies?

Speaker A: I uh, mean the general cloud business. Yeah, come on. AWS released their first service in what, what was it like 2003, but specifically AI cloud. I think this is a little bit uh, of an artificial niche to be honest. Right. Because uh, while the demand for AI workloads is immense and it will only grow, but uh, with the whole penetration of the market and growth it will blur. And I think in five years we won't be talking AI clouds, it's going to be clouds again. Just clouds. Uh, but even for AI specific workloads, there were a number of American companies that were way earlier than we were. Like Core Weave is a nice example. Lambda Labs were pretty famous when we started Cruzo, uh, is still somewhat relevant et cetera. Most of these companies kind of phased out of like cloud cloud business and focused more on like building large scale facilities etc. Uh, but they were definitely, definitely not the first.

Speaker B: Yeah. Who are some of your customers that people will recognize?

Speaker A: It's a hard question for me because I'm not sure which customers I'm supposed and not supposed to disclose.

Speaker B: Okay.

Speaker A: But we are pretty proud about the ones that we can disclose there on our website. But I think we've had a chat with every major AI lab out there for sure some of those are our customers. Um, a lot of AI, uh, friendly enterprises. The companies that you don't really think about as like well this is an AI company actually have a lot of AI going in the background and they are also the customers. So I think um, there are some logos that everyone will recognize for sure.

Speaker B: It feels like a very interesting space also niche right now but maybe it's going to normalize later on. For the engineers that want to go into this field because they love infrastructure, they love AI, might be a good match. What do you typically look for in the capabilities that they bring to the table?

Speaker A: Well there are several streams right. So first there is like the general infrastructure engineer track. Right. So anyone who is knack for infrastructure, who understands uh, the responsibility and uh, the scale and distributed systems is always welcome to the team. So we just hire those people on spot. We don't require any prior AI experience. Being the cloud and especially the cloud on the frontier of the hardware you can't imagine how hard it is uh to be I don't know one of the first to adopt new Nvidia chips uh in production for a large customer. This comes with the toil. So naturally people who are deep into like systems programming, figuring out what's wrong with the drivers on the hardware level etc. Also in great demand, low level storage people because and AI workloads, uh, it's not just about GPUs. Right. It's about immense demand for performance throughout the stack, networking and storage included. We routinely have customers who I don't know uh, download around hundreds of gigabytes per second of data sets while training uh, for that training runs. You need infrastructure and services to sustain that so that uh, comes in handy. And with the recent developments link now newly found focus on inference. Also everyone who knows how to Write kernels, program GPUs at a lower level is also like in high demand. And those I think are uh, one of the most well paid and in high demand people in the market nowadays. Because we definitely see the shift from training to inference as in running models. And in order to make uh, inference really like uh, well behaving and performance and everything, you need to change a lot at the lowest level of how those models are run on GPUs. And I think there are several hundreds of people in the top cohort uh, out there in the world.

Speaker B: Yeah.

Speaker A: Not more.

Speaker B: Can you walk me through your hiring process? So if someone is excited about this, wants to apply to nebius, do you have the same hiring process depending on teams or how do you typically have that?

Speaker A: It depends on the person, the background and what we are uh, talking about. But in general our hiring process is more or less standard for everyone. For all uh, venues it might have specialized interviews for if we're talking about some deep expertise. But in general we have a lot of uh, coding sessions. We have algorithmic sessions for everyone always. We tend to have systems design for example, but again it's optional because for example for a low level GPU programmer that has spent years uh, writing C code, uh, probably systems designed for distributed systems is not the best way uh, to assess them. But in general we have some specialized sections. Then after those interviews, if it's not a very unique case for the expertise, someone building networking stacks for the past 10 years probably will lean towards like the relative, like uh, to, to the relevant team. Right. But if it's not, we uh, usually don't choose teams at the very beginning. Like we make sure the interviews are passed, we like extend an offer, but it's an offer to join the company, not the particular team. And then we get into this, we call this process bootcamp endeavor to find a proper team for the person to find a match. Because I strongly believe like while hard skills and expertise matters, soft skills and in general compatibility with the people around you matters way more for productivity for like work life balance if you will. Right. So usually people have several teams they are supposed to join in the first three months. So they spend like four to three to four weeks per team. And in general they are just brought up on board it and I include it in day to day daily meetings, talking to product managers, project managers around, going through daily standups, for example. So the person uh, goes through this process for four or three weeks, uh, changes team several times and at the end have kind of an exit interview. So we reflect on what has happened during these three months. Uh, how was the onboarding structured? That's my personal issue. I'm always talking. And by the way, these interviews, uh, are always conducted by me personally. M and that's what I pay attention a lot into. How efficient was the onboarding, how much did the person spend in vain, et cetera. So this internal metrics of sorts. The onboarding should be fast. You need to be productive. You know, day one, day two, if it's a week, it's like the person spent three weeks on your team.

Speaker B: Yeah.

Speaker A: Like, yeah. Uh, we ask the person which team would they like to join? Uh, and we ask the team leads if they would like this person to join their team. And if there is a match, so be it.

Speaker B: Has there not been a match and what happens then?

Speaker A: Uh, it depends on how the bootcamp, uh, went on. In general, if there is like a serious mismatch, for example, a person thinks that the match is with the team that is like was gave a definitely negative feedback. Uh, we would treat it as probation period, failed sometimes.

Speaker B: Wow.

Speaker A: Ah. If it's less than that, like there is some hesitation, etc. We usually discuss it very openly that the feedback was like that. There's definitely a mismatch. There is like a, like, you know, second team in your preference. Would you consider that? We do understand that this is not the perfect situation, et cetera, et cetera, et cetera. But in general that's, that's rare case. So we are usually talking about exceptions rather than a rule. People generally tend to find the team they're comfortable with.

Speaker B: Yeah. Let's break it down for hiring algorithms, system design. Can people use agentic tooling within the hiring process? No. Why is that?

Speaker A: The honest answer is that we don't understand how to treat that and how to work through that process. On the contrary, we actually like. Oh, you know, like when pandemic started, Covid, et cetera, everyone went remote, all the interviews went remote. And we are actually now started like the backwards process and we are bringing people sometimes from another country, paying for their plane tickets and all bringing them back on site to conduct on site interviews face to face. Remember five years ago that was a thing.

Speaker B: Yeah, I had that.

Speaker A: Yeah, I think everyone had that. Right. But uh, now like especially for select people who we seem more senior and more uh, interested in like getting to know, we actually bring them into the office to connect to conduct an on site interview. And the whole agentic during the interviews, it's a mess because uh, for our process that would mean that we've gone through a lot of investment and maybe we don't get the person that we really interviewed, because algorithms and coding is. There is an argument that algorithmic sessions are bullshit. No one writes that code, uh, for their production use cases. And that's true in a sense. But this is a very good, uh, baseline to understand whether and the person's computer science background or knowledge in general is up to a certain standard or not. And we think this is quite a strong signal of what will the quality of the work of the person be in the future if they can write a simple algorithm or not. Like a purely algorithmic task. So adding noise to that with, like, you know, this, like this model interview cheating tools are crazy, right? Like, they're really good. No, nothing. Like, uh, you can't even by looking at the person, determine if they are, uh, like, having assistance or not. And like, I think that's a problem, and I really don't like it. So we are designing a special agent coding session when, like, we would, uh, assess how a person interacts with an agent. What are they doing? How are they steering the loop? Like, what's the task? How do they decompose that? How do they think if that works or not? Uh, but it's not on the menu just now, but AI assisted interviews are a mess. Don't like it at all.

Speaker B: Gotcha then. Zooming in on the bootcamp, I love this idea of just hiring people that are really, really good if they're not very, very specialized. Because for those specialized people, you probably have specialized teams that is just a match. But for the people that can kind of go anywhere and can go in and out of teams, I feel like very senior people are very capable of going into a team, solving problems and sometimes overarching teams and solving problems across teams. So I like that this is part of your onboarding, part of a matchmaking.

Speaker A: And it's not just for very senior people, because people who are less experienced, I feel like they actually get more value out of the process because they don't really know what they want to do and they don't really know what will defeat be. Sorry.

Speaker B: No worries.

Speaker A: Uh, and being able to look at different teams, being able to get more context of what's going on in the company in general is a very good thing for them. Because more senior people, they're just, okay, I'll figure it out. And they usually do less senior people, they require some guidance there. Right. And this process is essentially designed because, like, uh, all the teams work in collaboration in general. Right. So, for example, uh, there is, like, it's not a rare case when a person is designing some kind of a feature in one team changes team within the boot camp. The next team, they actually on the team that is like, a, uh, client of that feature. So they immediately see the value. They can reflect on what was done, how the interaction was structured, et cetera, et cetera, et cetera. They pass the team, like, okay, next team has nothing to do with that. And their fourth team, like, for example, they are actually on the dependency side of the first feature and all the struggles that they had while implementing, they can see, why did that happen, and they can think of how can that be amended or fixed, et cetera, et cetera. So in general, understanding more about the team's internal stuff being more transparent to each other, it helps, and I think it sets the right tone. From the very beginning, we are very open team. We're very transparent about what. What's going on. We talk about our problems, and we show our problems. During the bootcamp, like, a person can see the whole cycle.

Speaker B: Do you then specifically look at teams that have availability, or do you just hire really good engineers all the time?

Speaker A: Yep. We never stop hiring. We're always pushing our talent acquisition team to bring more people around. And, uh, our interview is somewhat, like, rigorous and might be. Might seem like an overkill. Sounds tough. Yeah. We don't hire a lot. Right. I think it's usually, like, 10 to 15 engineers a month. It's rarely more. I would like to have more, but we don't. And then we don't. Like, uh, like, uh, I spent probably half a year fighting at an earlier, uh, stage of the company, fighting with my team leads and people who report to me, uh, forbidding them to use the word headcount. There is no headcount in our company. We don't talk headcounts. We talk demands, we talk tasks, we talk priorities, uh, we talk size, uh, of the backlog. We don't talk headcount. So we don't have the concept of the headcount. So everyone can hire if they see, like, it's something they need. We have, like, a little internal system that would balance, like, uh, the amount of boot campers, for example, the team team gets. Yeah, but they have a choice. They have a save who comes, like, so they can preview the cvs, the interview results. See, that would be a potential match and only, like, ask or get in line for very particular people. And, uh, yeah, so we just hire and, uh, it's Always like. But what if we hire like 10 people and don't need 10 people. The answer is usually, let's see when we get there if there is an issue and I see there is an issue, or someone says we'll have a chat and we'll figure it out. So far we didn't have an issue. Nice.

Speaker B: Uh, you and I spoke before the show and you mentioned your engineering population is about 300 people.

Speaker A: Uh, it's closing 400.

Speaker B: Closing 400. That's only in Amsterdam based.

Speaker A: No majority, uh, is in Amsterdam. Well in, in the Netherlands.

Speaker B: Yeah.

Speaker A: But Netherlands is not like a large country. So everyone can come to an Amsterdam office once in a while. Majority, uh, is in Amsterdam. We have like a healthy presence in London and we're actually focusing on, on London a lot these days. I have I think 10 is percent spread remotely around Europe everywhere. Like from Portugal to Baltic countries, from Finland to Italy. Yeah, right. Uh, we have some presence in Israel. We have some presence in the U.S. yeah, that's it.

Speaker B: But you've spoken to kind of all of the hires when they come on from a boot camp perspective.

Speaker A: Boot camp? Yes, I like I've spoken to all of the hires, especially in the early stage of the company right now. People who go directly to teams like highly specialized, I usually don't and like a proper interaction. And we've recently been on, on an M and A spree, so I've definitely not had a chance to talk to everyone who joined with like with the quiet companies.

Speaker B: Gotcha. Yeah, I feel like it's fascinating to have this kind of onboarding process where people join multiple teams and then game perspectives. It sounds like a lot of fun, like coming into a company and like

Speaker A: I actually think everyone wins. It's a clear win win situation. Like it's not a win win for everyone because sometimes people tend to be tired or it's like, oh, it's a burden. Right. To change context every three weeks. Especially if you like, uh, feel like it's a challenge to get on board, et cetera. And um, there is that aspect. But in general I think it's a win win. Like it's a win for an employee who gets to see what's going on around, which is extremely important. Uh, it's win for employee that can actually match the people who they actually vibe with because it's very hard to understand whether you'll be, whether that's going to be like a good match during final interviews or like just reading about the team. Actually you need to see the people of course, you need to see how talk. What's the mood around the office? What are the memes that they post into internal memes channel. Because like I'm telling you from experience, not everyone is compatible with the same memes. Of course. Definitely. It's very tasteful. Yeah. And uh, like, what's the attitude from the peers from product managers? Is it like, do we like it or not? And that's a big deal. And for the company, uh, first it's well, relaxed and happy. Employees is always good productive and teams become very productive because they actually find people who click together very well. Uh, it's a good thing for the company because for example, team leads see this constant influx of people. They see new people so they are more relaxed about uh, talking about performance. For example. Right. There is no commotion of, oh, this person is like not really. Well, like not a good fit for my team or underperforming. But I will just hold on to them because if, if I get rid of them, who's gonna work?

Speaker B: I lose my head count.

Speaker A: Um, yeah, I lose my headcount. Sorry. Yeah. So like, and team leads are usually like way more relaxed because they see the constant influx of people. Like we are constantly hiring people are constantly cruising the boot camp like, like what, uh, 40 to 50 people, like maybe 20 to 30 people. Always like in the loop, everyone sees that they are there, uh, etc. So in general I think this, this works really well for us. It becomes a burden for me personally sometimes because like you, there are days when I have like three or four like this bootcamp and meetings, but I still maintain it.

Speaker B: Yeah, very interesting that from a title perspective. And this was also me a few years back. I've spoken to more and more CTOs now, but this seems like I would expect CTOs to be very much technology focused. And I feel like you put a lot of pride in kind of team dynamics, engineering culture across the board also in your involvement in these boot camp sessions.

Speaker A: I, I'm not sure CTO is a technical, uh, role, at least at some scale. It might be for the smaller scale when you are a startup that like uh, everyone is doing everything in CTO is just a guy who like loves tech more than anything else. But in a sense after a certain scale it's a, it's a management position. It's less about tech, it's more about building the team, making sure delivery is there, making sure there is no conflict between engineering and product function, engineering and business function, which trust me, there always is stuff to like to quarrel about and to argue about, uh, it's more about structuring the hiring and onboarding process, etc. Of course you need to be a techie, you need to be able to assess what's going on, you need to be able to dive into projects, you need to be able to dive deep if needed. But it's not your day to day, it's not, it's more about management. It's management and the technical organization. And I, uh, think the larger the scale is, the less tech there is.

Speaker B: What are some of the skills or capabilities that makes a CTO successful?

Speaker A: Good people person, good manager. Like people manager. Uh, being flexible enough. Like I usually describe, uh, the role as, you need to be an advocate for the engineering team in front of business function, for example, and at the same time you need to be the advocate for the business function in front of your engineers. Like, you need to bring like sanity checks to business, both sides of the table. And you need to be like this, I don't know, uh, constantly in the middle person who reflects on both sides of the equation and makes sure that everything is balanced. Uh, I, um, think, well, it's less about the CTO role, but I think it's more about any manager in the modern company. Uh, one of the main skills is you should always be managing expectations of people around you. Like, I, I think this is the main thing a modern manager is doing. And every failure I've seen usually comes from not managing expectations. Right. Even if you are not capable of delivering, if you're not capable of doing something properly, if you're not, if you manage the expectations right, the, the result will be way better than if you just close out and like struggle on your own and don't tell everyone, like you have problems, etc. Etc. So being in the middle, being able to talk to everyone, uh, accept their point of view, internalize that and manage expectations.

Speaker B: Why do people fail sometimes to manage expectations? Because it seems so simple when you lay it out like that.

Speaker A: Because people are people. Pride. Uh, uh, fear of seeming incompetent. Like ego. Ego or pride Ego, Yeah, like I can do that, I should be able to do it. Or I promised, like in general, fear of communication, of open communication. What will they think about me if I tell them I don't deliver. Imposter syndrome. Of course, here we are. But in general, like, it's hard to admit failure and well, in a sense it shouldn't. Like nothing's going to happen. Like if you're open about your achievements and Failures, people will actually, I think they appreciate it more because no one likes people who are bragging about their achievements, right. And like discounting their failures. No one likes people who like, bring their families as a surprise. Because like, it's not about just managing expectations. You need to remember that everything that you've said out loud, someone heard, internalized, and probably have plans based on what you've said or committed to. And there is a lot of stuff in motion that you are not aware about that might have like a long chain of failures. If you fail to deliver or fail to manage expectations of people around you and you can't formalize that, you can't say like, I didn't write an okay in that particular ticket, hence you shouldn't have acted upon that as I did. If you had a conversation and you've said it out loud, you're gonna do. Doesn't matter whether you said probably. It doesn't matter if you said I'm uncertain. It doesn't even matter if you've directly outright said I will do it. But don't count on it because the second part, no one will remember. They will only remember the I will do it part. So you need to be very cautious about you. And it's not cautious as in don't commit to anything and don't talk about anything talk. It's a good thing to give people indications, etc. Just don't forget what you've said to them and go and adjust the expectations, etc.

Speaker B: Gotcha. Yeah, I want to shift gears and talk a little bit about agentic engineering. Some of the.

Speaker A: That's some shift.

Speaker B: Yeah. Yeah. I feel like some of the bigger organizations are really questioning their engineering capabilities, distributing tools, trying to figure out how to make their engineering work more effective, because that's the promise. How do you view agentic engineering currently?

Speaker A: Oh, it's a constant source of like internal arguments, especially with our CEO who's like very bullish on it.

Speaker B: Hype.

Speaker A: Yeah. Why, why? Why isn't like 90% of our code written by AI? Like, yeah, because AI won't wake at 3:00am um, uh, like when there is an incident production. Okay. Might have come out wrong. For in general, I think, uh, it's very weird to, to say that it's not happening. It is like 100%. You can definitely see it. Uh, I think the inflection point was roughly this winter when, uh. What was it? I think Anthropics 4.6 and GPT's 5.4 models were released, which really raised the bar and with more than 4.7, 4.8 GPT, 5.5. These are extremely capable models and with the right agentic loop, uh, harness and with the right tools it is capable of serious engineering work. I think the promise of agents will do everything is not at this level, not right now, not in the near future. Everyone who talks about software factories, it's new term that bothers me immensely.

Speaker B: Dark factory.

Speaker A: Yeah. Agent will look at your production, fixed bug, uh, write tests. Tests, everything. Yeah. Everyone who had an experience on driving a self evolving agent loop in software engineering knows that it doesn't work like that, it never does. So I think we are way far from completely autonomous work and of course there might be examples of people achieving that but it's uh, up to a certain scale, up to a certain business scale for example etc. And I think the more most successful examples uh, I usually have like a human driving the whole thing. Right. So I think AI agents and agenting software engineering is here to stay for sure. I just don't think that the hype that we see out there is true. It's not that it's a tool, it's, it's just another tool. Like there was a hype about uh, like I don't know what was it, uh, what was uh, like uh, you know uh, at some point for example if you remember in the C Sharp community there was like a huge hype about the sharper when jetbrains released their tool and it was like yeah, this is like this is going to change everything forever. We're going to be so much more productive. Sure. Like it's just a tool now. Like of course no one writes uh in notepad anymore. Right? Yeah that is true. But uh, I think we're gonna like all the systems will mature and it will just become a commodity, just a tool. But in general I think like agentic coding is a very powerful tool. Like when people say that things uh, multiplication of like your performance or your productivity that might be true but also I think uh, the baseline, the zero and like in your skill that is going to be multiplied. It's not the, like you're not an engineer, it's way harder. It's like somewhere along your mid level to senior engineer and we all know what happens if you multiply a negative number. Right. So zero is up there. Everything lower is negative.

Speaker B: Catastrophic.

Speaker A: Yeah. And it's going to be M multiplied. So like that's where we sell. Like I've created a startup with cloud code in the matter of like One hour. Oh, and like Shockley like gets like whatever subscriptions like oh, everything is wide by, by hacker. Why did that happen? Well it happened because there was no sane engineer present in this loop. And in general models are not that good yet at doing large context, having intrinsic knowledge. They don't. Everything you see in the loop is like the model that it can't invent anything. No uh, pre training loop. And the general knowledge in the model will let it actually solve your task. So everything it reads, it reads right there in the repository or what you prompted, et cetera. And if you don't, it will not think about that, it will just implement it as is and tell you everything is working fine and it will be working fine. And like that's one of the parts that bother me about the software factories. Like people who write articles. But I just recently read one, uh, they managed to claim in the same sentence essentially that uh, autonomous software engineering is a great area because it's formally verified, you either pass the tests or not. Right? And the same sentence they say, and the models are very capable of writing the tests. So if your model writes the implementation and writes the test and everything is green, how sure are you that it's actually done a good job? For now there are like theories that it can be addressed by a separate model loop writing text and specs. But again uh, they converge very fast. Like they literally read everything that is in the repository, the recommendation, et cetera, as the ground truth because they need ground truth to start working. And without like external challenge, without external questions, uh, etc. You won't get anywhere.

Speaker B: It's just self contained information.

Speaker A: Yeah, isolated and it boils down to uh, very inefficient loops. That's why I think uh, from my personal experience working with an AI agent, uh, doing stuff and actually do a lot of stuff these days, I think for the likes of me this whole AI agentic revolution is like, it's great, fantastic. Yeah, because like I can drop my ideas into code immediately, have prototypes instead of like gathering sessions with developers, trying to work through the issues, planning, etc. Etc. Etc. And then just present the MVP and say like here it works, let's do a product out of this. Uh, but working with an EI agent is not dissimilar to working with a junior uh, engineer. They don't have the full context, they sometimes have weird ideas and they manage to talk themselves into uh, exploring these ideas and building. On top of that they require constant challenge from the outside, like showing the outside perspective, working with that requires uh, a decent internal bullshitometer. When you read the statement from a model and you're wait a second, this shouldn't be there. This is not how it's supposed to work. Like asking questions that would imply verification from something that is currently not in the context remembering what might be in the context of the model same as it like what was the way of thinking of this developer that reached out this conclusion? Right. So this is very similar and I think this whole actually it's not the software engineers enabler, it's the software engineering managers enable way more than like and even if you see engineers who are actually good and like increase their productivity with a agents a lot I think it's because these individuals would be a very good engineering managers. Interesting in a sense

Speaker B: do people in the organization have access to agentic tooling? Like have you widely distributed that? Have you only given it to senior engineers?

Speaker A: Uh, we have access not to everything. For example, we have access to OpenAI models and codecs for example and everyone can build their own harness with GPT. We don't give widespread access to cloud code. And for me the distinction is exactly the hype. Like people want cloud code not because they want an agent to work for them or not because they know what to do with it. They want cloud code because it's a hyped tool and everyone's talking about that. And this for me is an issue. We need more guardrails, we need more observability there in a sense I think I've recently posted it on internal Slack like manifesto of like when will we get ah cloud code? Like uh, I think we need to reach uh a state in our tooling when for every pull request that is supposed to be merged into a production branch you need to have a clear distinction whether this was written by a human or assisted by an agent. And if it was assisted by an agent you need to have a full trajectory. So the full session or sessions that led to this result ah m connected, open for audit etc. Etc. Etc. Because we are shifting in a way from actually writing the code and understanding if human have written the code you can hope to have a conversation with them about it. If the agent have written the code, you cannot have an honest conversation with a human. Oh M in the extreme cases when you should not commit the code that you don't understand which you can say but no one will do it anyway. But it means you need to shift from discussing code to discussing the way of thinking about the code. What did you think when you were designing this approach, what was the reference architecture that you had in mind? How did you drive the model? Did you challenge it enough, or, uh, did you just yolo it with one prompt, et cetera, et cetera? And this becomes an important question. So I would be very hesitant, and I am very hesitant, very conservative in this, to allow the widespread, uh, adoption of an overly hyped tooling. Uh, if I don't have enough guardrails and I don't have enough guardrails as of now. And we are building it internally right now, but we're not there yet. Uh, at the same time, I think the most capable software engineering model as of today is OpenAI's one. They constantly change a little bit, like with the new releases going back and forth and everyone who actually wants to build with it with an agent can do that right now. And they do. It's not just less hype, more practical work.

Speaker B: Interesting. I feel like some of the specification frameworks are trying to solve the challenge that you mentioned. When there is a code change, what is the context that went into that? But it's not addressing kind of the whole history of the conversation and how that specification came to be. I feel like we need more insights in intent and history on how a change came to be.

Speaker A: Yeah, in a sense, like it circles back, to be honest, to one of the interviews we have, like, for engineers that are, uh, higher than our basic grade. Now, basic grade is not junior people, it's higher than that. But if we consider a person to be more senior than that. One of the interviews we conduct is, um, technical due diligence. It's not structured in any way, but it's like it's a free form chat about a recent project that you've been involved in. M. And we don't assess architecture, for example, or the result of whatever happened. Like we have separate interviews for that. What we assess is general understanding of what was going on during the project. How were the requirements gathered? Why did you choose this way? Not in architecture way, but like, who was the decision maker? How was this decision adopted? Right. Why were you building it at all? What was the purpose of the product? What do you know about clients, like our users? How did they adopt, uh, like did you get any feedback from that, how was internalized within the team, etcetera, etc, etcetera. And this is the interview that we conduct for every engineer essentially who is like higher than our baseline, because this is the like. I think this is one of the more important qualities nowadays, and it loops nicely into agentic workloads, right? The person who actually tries to think out of the box outside of this particular task, thinking about the system in general, decision making process in general, like uh, what's going to happen with the product in general after it's released, after it's being used, tend to be like a better engineer. A more productive engineer brings more value to the company in a sense. This is like remember there was like uh, the whole DevOps, uh, commotion, right? Developers, operations. Now everyone's been together, let's do. The idea was that you don't need to just write code, you need to think about the system as a whole. I think we are currently in the next step with this whole agentic revolution. You need to think about not just the system as a whole, but product as a whole, implementation details, architecture, operations, how it's run, like whether it breaks or not, who is on duty today, et cetera. And then the product thinking, right, why are we even doing this? Do we need to challenge the product team that brought this new feature? How will that loop into the rest of the product or the system, et cetera? Uh, I think we are like, remember like uh, t shaped people, etc. We are going to the round shaped people. Like you need to be a little bit of everything you need to be, but in a sense you just need to be uh, a generally smart and sensible person and that's it.

Speaker B: Yeah, I feel like it's easy to say and for me I always had kind of innate curiosity. So I'm just interested uh, about what am I building but also for whom and what problem am I solving and why? And if that doesn't make sense then I shouldn't do it, but I should focus on something else. Like it was always there rather than focusing on how I built things. I think that's where it started from me growing into junior engineer. It was very much a uh, problem how do I do this now? And when I got more comfortable it was well, should I do it in the first place? Because I now know how to do it. Like that's not interesting anymore. And I feel like I quite quickly pivoted to a point where I could definitely do with more depth in terms of hard skills. But I just feel like my curiosity drove me towards the more overarching thought. In your, in your perspective, from your advice, engineers nowadays, do they focus more on kind of the what, why and how or more on their hard skills? Because I feel like hard skills are partially being automated in terms of generation.

Speaker A: Yeah, it will become obsolete in A sense. Um, I've recently had a chat with a number of students and they were like, but okay, we are in the university right now finishing our computer science degrees, et cetera. How do we get into that? What is our career path nowadays? Previously it was obvious, you go to intern position, junior position, you sit alongside the grandmasters and you learn how to do stuff and you acquire these hard skills, etcetera, etc, etcetera. But now with, with agents doing the junior work. Anyway, like what, what, what, what is the, what is what, what is the place for junior engineers anymore? And I think this is a misconception in, in a sense because like people who have a knack for that, like smart people, curious people, like people that can uh, who are good at decomposition, right? Like figuring out what are the parts that combine as a whole. They are good with agents and they will uh, they will still find a place and they will be great. And it's like yes, of course you need more experience and you need like this baggage, right, uh, while you're growing. But it's, it's important to acquire. But it's not about hard skills anymore. No one cares about the framework, no one cares about a particular library. No one cares if you know all the instruction of an x86 processor. It's a good thing to have because it like implies you are, you have some knowledge in some package. But it's, it's not a requirement anymore, it's not how you measure people anymore. And um, I think we will still have people who are digging deep and who are bringing the frontier. It's just not a requirement, it's a specialization, it's not a requirement anymore. But thinking about what's going on, how to structure everything, being able to produce a uh, concise flow of thought, which is an extremely hard thing if you think about it. People are not generally good at that. Uh, this is what becomes of value. And yes, this will change how we view engineers and this will probably change uh, the composition of these teams. And uh, some people who have a great career will phase out because previously you could go, I don't want to sound derogatory, but there is a special cohort of engineers that I think will vanish. For example, uh, people who sit in banks and automate internal processes in Java, this, banking, Java developers, this is something that, this is a cohort of engineers that are at risk right now because very task oriented, very mechanical. Uh, these are the organizations that we are not even talking about this whole common sense, let's build a product thinking organization uh, they're not even like, they're not even thinking about operations because they're a separate operations teams. This kind of engineers will become obsolete in, I know, three to five years, I feel. So there will still be inertia, but there will be no new influx of new people into those teams. There'll be no influx of people who will be able to, to think of that as a career path.

Speaker B: What happens to the systems they are responsible for if no new influx of people come out? They will modernize it.

Speaker A: Yeah. Um, in a sense, um, I think people are definitely worse than even modern agents of figuring out of what's going on in a complex, uh, code base. Way worse. It's just not how we're built. So the only thing that is there is this intrinsic knowledge, something that's not written anywhere that only exists in someone's head. But it's not about the cohort of engineers. It's about particular people and particular skill set and particular environment and particular engineering manager who was okay with the bus factor of one and never pushed for knowledge exchange, et cetera, et cetera, et cetera. So it's like it's less of an engineering problem, more of an organizational problem. Yeah. And sure, like uh, having a job security by not writing documentation in around for 40 years now at the very least. Right. And this will still be a thing. Yeah, for sure. But uh, we're not talking about that, about talking about ingenuity.

Speaker B: Yeah, I, maybe it's because, um, I see myself still as a little bit young or eager, but I don't know how people get into a position like that where they are just ingrained in a small cog in a big organization like bank or insurance, very small moving or slow moving behemoths.

Speaker A: It's stable.

Speaker B: That might be it.

Speaker A: Yeah, it's stable. It provides decent benefits. Um, way better work life balance than working for a company like ours, for example. Like we run a full like responsibility cycle. You build it, you own it. Like you have uh, freedom to design stuff at will. Don't have like architecture committees, no boards, nothing like that. No architects as a separate position. Right. You're an engineering team, figure it out. But you build it, you run it, you run it, you're responsible for it, you're responsible for it, you're on call for it. Even if it's like Christmas night, 3:00am um, it doesn't matter. Someone from the team is on call and is supposed to react if something fails. Good work life balance. Probably not uh, enough people who are willing to Engage in this kind of

Speaker B: situation for sure, absolutely, yeah. What if the agents write the code? That kind of all. You build it, you own it, you run it, you're responsible.

Speaker A: I feel like that's why, that's why we are not there yet and I don't think we should be again like uh, I think at this day and age, uh, committing production code uh into like in a product that runs, I don't know, multiple hundred millions of like yearly revenue should uh be owned by a human. It's non negotiable. We are not there yet. In terms of agent AI capability, you can't rely on it. It's just like, well you know, it's a meme by now like ah, chatgpt and telling you oh you are totally right, I made a mistake. Yeah, I've seen it too many times. Absolutely right. So we still like human driven and human responsible. You can augment humans, you can help increase their performance or uh, automate some of the process. For example, we have a lot of agentic workloads internally. It's just not about software development. Development. Right. For example, if there is an incident production agents are actually pretty capable and good at finding the current root cause or coming up with an immediate mitigation plan simply because they are faster. And this is more or less structured environment. Right. You have like a recommendation, you have your metrics, you have the logs, you have kubernetes that you can uh, explore. And a human can do that, but it will take them like 20 minutes. An agent can do that in three. This is a good thing, right? Or when we are talking about like cross checking, cross referencing stuff, it's also like something that the agent can do great. Nowadays, for example, when you're writing a postmortem, producing a postmortem by an agent in my experience is a shit show. Doesn't work. But checking and cross referencing and grounding the facts is something the agent can do very well. Like we have agents right now who can look at the document, go to Slack monitoring like kubernetes and fact check every statement in the document. Whether it's grounded, where it's like was it like that? Correct. If it's not, provide feedback on for root cause analysis. For example. This is a great thing because people can like not notice something or they can skip something the agent won't because they don't have a modicum of like trying to conserve the energy.

Speaker B: There's no ego there.

Speaker A: Yeah, it's less about ego. Like human brain is optimized to Conserve energy. They tend to not do stuff diligently. Like it requires a lot of willpower to do stuff diligently. And of course there is like a sleep here and there always will be. It's just part of human nature. So this is where you can get the slope of grounding and making sure that everything works, et cetera. So again, augmenting people, not getting rid of people.

Speaker B: Gotcha. Um, one of my last thoughts was I think a combination of what we discussed so far because we mentioned from a focus standpoint, if you're new to the field or already kind of a little bit more early in career, things are being automated in terms of capabilities. So focusing on hard skills versus some of the other skills that you also need might be better to focus on the other skills more, the soft skills, more on the why and the product thinking. But you very specifically mentioned that algorithms are still part of your hiring flow. Like if I would want to join Nebius right now, I would fail specifically probably for those algorithms. It's something that I would have to train and I would probably not really like it, enjoying it kind of memorizing the algorithms. And I do think it might be good practice, but I wonder why that is still a thing. And when are we going to get rid of algorithms within an interview process?

Speaker A: I don't know. My uh, answer is for us specifically is when we find another way to provide a good baseline. So algorithms be enabled for. It's not about memorizing, to be honest. It's about like yes, it is about some patterns that you need to know and uh, approach. But it's rarely like the tasks there are really about like remembering a particular algorithm and implementing that. Right. It's more about thinking uh, algorithmically, knowing when you can cut corners and when you can't, knowing about like a broader subset of lower level primitives, etc. And um, for me, for us, uh, it's separating like people who are into tech from people who are actual engineers. I'm sorry to frame it like that. Right. Because uh, we are still looking back, you need to have this internal understanding of what can go wrong. And you can either have that with experience or with education. And I still think that for a lot of computer systems this is an important part. You need to be able to think about data structures, for example, uh, agents won't be able to solve it for, for some time, the very least the whole optimization cycle. Like, you know what the modern optimization cycle with agents, uh, is just go run hundreds of uh, theories and maybe one of it will like genetic algorithm if you will. It's not the best approach to be honest. It's prone to like uh, finding local maximum and never exploring further. It's. This approach is not what made uh, all the greatest inventions in human history. Right. No one have invented anything new just by digging and uh, trying multiple times around the same area. So again like circling back to algorithms, it's still just ah, a signal whether the person is actually has like some well, computer um, science education. Well education is uh, I use the word education as an umbrella term. Right. It's not about the university or a particular course. It's whether you have this uh, understanding erudition if you want about how do the computers actually work, how does the software actually work? Because this is important because not all software is just like taking JSON from this API and sending it to another API. There is a uh, part of the market and a huge one which is exactly that. We are in a slightly different game. We build infrastructure for those who do that and hence we think it's still important for us to have a certain level of people who are into certain things.

Speaker B: Dan, thanks you, thanks so much for coming on and sharing. This is great.

Speaker A: Thank you.