# AI Forward Deployed Engineer Playbook - **Plataforma:** Maven, lección abierta detrás de un email gate - **Duración:** 50:21 - **Origen del texto:** subtítulos oficiales del master playlist HLS (en) - **Video:** https://playgrounds.digitalhubassist.ai/maven-ai-forward-deployed-engineer-playbook.mp4 - **Subtítulos crudos:** https://playgrounds.digitalhubassist.ai/maven-ai-forward-deployed-engineer-playbook.srt - **Palabras:** 9122 - **Bloques:** 85 --- ## Transcripción **[01:00]** We'll start in a minute or so. Yeah, so we are ready to get started. So if you guys in a place to switch on the camera, please do. **[01:43]** We'd love to see some faces. That's only asked that I have time. I would love to understand who's in the room. What's your background? What do you do? What's your interest in party club engineering? And then again, you guys are playing for roles. Like what's your general of black questions you may have. Also, feel free to share your. LinkedIn as well in the chat so that others can join us as well. Hey, so how are we doing? Thank you everyone for introducing yourself, but yeah. **[02:35]** Yeah, if you can rename yourself as well, so others can know who's in the room. That's helpful. Thank you. Yeah, and as an engineer, feel free to share LinkedIn so others can connect. So I'll jump into it. **[03:09]** So these sessions are generally like discussions at the end of the day. I do have a slide deck, but I would love to hear your thoughts as well because I'm good. Like you guys to ask questions to make the best of the session. So especially if you guys are playing for jobs and then like looking too. After you roles like what that looks like would love to hear that. Yeah, so, I mean, the term is quite popular these days. I thought it was engineering. So I'm going to try like breaking down as much as possible to sort of like. Explain what everything means and then like what it looks like in different **[03:43]** places because different firms would have like different variations of the role And then like how the interview process looks like but sort of skills you need to have. All right, so the focus today is going to be sort of like looks at a bit about why. Sort of this general gen AI sort of solutions fail or in the world. So you might have seen a lot of reports about it and going to some sort of like articles about this are some statistics around this. And then we'll look into like what an FTE is like what's a vertical engineer and then sort of like going to like what they do, like pushing things into **[04:20]** messy systems and then how do you sort of like deal with like actual clients. Because there's a client facing component to it, not just the engineering side. And then how do you like crack the interview for this, which is quite. I think like is adjacent to like engineering roles, but it has a bit more nuance to that compared to just normal engineering roles and then at the end of Q&A as well. All right, so you might have seen this, there's like MIT sort of published article about like this. It's like 95% of gen AI deployments, like this is relatively old like last year **[04:58]** , didn't like 95% of them sort of delivered zero measurable sort of impact. So it was quite alarming, given that everybody was on the AI set like bandwagon . And then again, like when you look at the results, like there's a lot of mistrust and dissatisfaction on places where these things not get enrolled out. So this is a common situation like last year, and to address this is one of the main reasons AIFD roles that like came about. And yeah, so if you look at it, like these are some of the other reports that I found out as well. **[05:34]** So, I found out as well, so garden, I said like 40% of the, um, agent to get projects will be canceled by 27, 30% of these BCG, like 3% like AI, effortless people and process non algorithms. So the idea is that like you need to like sort of bring in a lot of these people who are currently working in these places like to actually into the mix. And then, so Mackenzie report is like Mackenzie finds that 8% from CCA, but only about 6% are high performance. So, so there's something like the stats about it. **[06:04]** So, and then like to address some of these issues are the AI for deployed engineer role is created. So just like another staff, like 2% of the externally part part of the tools succeeded. The reason is that rather than you just go and like selling a solution, like you need to like set of like work. With that team to implement that your product within that team. There's also like debate around this whether this is a good approach, getting to that at the end because there's like a lot of mistrust around like players that can't open AI trying to like get IP from different clients. **[06:42]** There's a whole other debate, but when the market is going, this role is currently at least like from a hiring point of view, make a lot of sense, a lot of people are hiring. And I'll show some of these acquisitions that sort of like sort of like talk to that. So let's look at like what FDE is right 40 per engineer, and that's the main thing we're trying to make sense. So the term sort of came from Palantir. They had this function called deltas. They focused on just one customer. They go and sort of like help them implement the solution and this will expand from there. **[07:15]** And it's comes from these like four deployed units in military because Palantir being like consultancy slash sort of like service provider for defense tech. What they sort of like had this role is that they had a few engineers like who goes and work in the actual field, like in the battlefield, trying to like test this software that they build. So this is where the name comes in. Now, so everybody sort of like sort of like took that and implement within the asset open and it has like FDEs and that Google has FDEs. **[07:47]** Everybody has FDEs. So it's not like necessarily the actual battlefield, but you had client science trying to like implement what you'll have. So pretty much it is very similar to like a startup CTO role where you have to like actually deal with a lot of problems and then like come up with solutions as you go. That this is the starting point. So, but it's good to like position this like with other types of roles. So you have like sales or solutions in general is a consultant roles, generally it might consider consultants, and then there's like product engineers. So, sales solution engineers, they do demos and POCs, but these solutions would **[08:24]** not necessarily go into the client's application side where consultants may not most of the time build products. I mean, still make build POCs right now, but it's pretty much as advisory, giving a roadmap on how to do things. Where co-product engineers is pretty much like you focus on working in your product. For example, if let's say open AI and Tropic has product engineers, they focus on the model side of things. They work internally to improve that where FDEs, the idea is that you actually go and like work with your client and try and implement that within their system. **[08:55]** And the code that you write is actually production-ready code. So you're not just like building demos, you're actually working with that team, you sit within that team to like implement that. So that's the general, I would say, 90% of the roles would actually fit into this definition. So it's good to understand this so that you sort of understand what you're getting into. So this is like another example that I saw, like for example. So these are two acquisitions that happened, like so open AI sort of acquired a company called Tomorrow. This one, now it's called DeployCo, which is they have like a bunch of FDEs, this is high like fast-growing startup in the UK. **[09:34]** And they sort of acquired them to be the external like this for deployed arm. Similarly, at the same time, and Tropic and Blackstone launch ODE, which is 1.5 billion implementation partner to implement and Tropic within different clients So this is like early like a few months back. But this is just an indication that a lot of these big players, like even Google does it right now, are pushing to acquire for the engineers because it's a very unique skill set. **[10:06]** For example, DeployCo, they had like the predominantly focused on opening and deployment. So this is health, it was an easy acquisition play for open AI because the people like who worked in that team are pretty much experts on opening and ecosystem. So it's a no-brainer for them to acquire likewise for the ODE as well. So the idea is simple, you get a bunch of people who are experts in the products that they're selling and also have consultancy experience, you sort of like get them to go and like do the implementation for you. All right, so if you look at the demand, I think like you might have already **[10:40]** seen this. Like a 700% growth on this. And then, and recently it says the hottest job in startups these days, obviously these are like take these things with the grain of souls because obviously people like to hype it up. But looking at the hiring at least, this is getting like quite popular. The main reason is that deploying AI out in the wild is quite hard. So you need like not just like just one of implementations, you actually need somebody with the right expertise to like work with them for a very long period of time. Like at least six months, so that you can make sure these interventions work. **[11:14]** The models work and the right, the adoption works really well. This helps both sides because if the integration works, it's good for the model providers that we can have a client for a long period of time. And it's good for the client as well because you have an expert from the specific team to actually help you figure out like what sort of work first to implement. So that's the main reason behind this being quite popular, especially in the AI center implementation side. So, one of the things like you will probably need to like get used to is like shipping into my systems because you're going into like a totally different **[11:49]** ecosystem for what you're used to the already systems running. Already workflows that going like these are like ad hoc excel sheets like different kinds of things you're looking at. So you need to like make sure that you're quite comfortable with that. So this would be like a general process that you may do, for example, you spend a lot of time scoping, like understand the requirement, talking to clients. So you sort of like go and work with the team generally in person or you remotely, you sort of like sit with them to talk to that. I'll say like you probably spend like 60, five to 70%, maybe on this, like you **[12:25]** actually like spend a lot of time trying to figure out like what needs to get built and you scope it out really well. And then on top of that, you define the validation layer as well like how do you like make sure what success looks like. So these could be emails could be like system checks like whatever that is like you sort of like define that as a lot of front. So the problem, the validation is defined then after that you go and deliver that so that so that so more time you spend on this planning space stage one and two, the delivery becomes much more easier for us to. So that's where like the general after roles that I've seen work out in the world. **[13:01]** Yeah, so I think like if you break it down a bit more, this is some of the sort of the best practices I've seen, like you generally put emails before model so that's why I like things are quite important like you make sure that you define success criteria and based on that what emails looks like and then you implement that generally rather than trying to sort of absorb this massive scope, you try and like build relatively small scope like get one workflow one sort of like this process automated. It's much more better to have like a reliable repeatable automation rather than **[13:37]** this build out like massive transformation because it's very hard to like maintain just in one goes generally layer by layer you sort of build it out. And also like you generally would have human in the loop so that means like what are they generate you're trying to like put as much as possible touch points to get approval from human so that you can actually look at these results here human in the systems, like could be domain experts engineers themselves, so that you can like make sure things work as expected. And then you kind of like focused on a **[14:13]** lot of like logging and monitoring you put the safety net first what that means is like you put the right kind of of space except try to see like if things are working sort of ties back to us as well to a certain extent you're looking at up you have to like make sure like have a good sense of how the systems work. And then you have a budget for on glamorous work what that means is like there 's a lot of like data engineering work you're like talk to people like back and forth like because. I do a lot of these work, and like when we go to like different organizations I have to like work with different teams. So they are it team department might **[14:50]** have like a very specific way of working sort of understanding that and sort of making sure those things are aligned is takes a bit of time so it's very important that you budget for that as well because there's time commitment that needs to go into making sure things are set in that way. It's not just building a models like handling this as well. You know this really well. All right, so you also need to like make sure that you plan for to deliver something so like mid market sort of like firms you're looking at 90 days to production, larger enterprises up to nine months and then Sierra and I go on **[15:26]** these. All these are like sort of like implementers they've sort of like mentioned like two weeks to two months for implementation where they go on says like six weeks to from this card to deploy. So it depends on the firm as well, but if you're looking at mid market like large enterprise, you're looking beyond like three months or even six months to deliver something so it's a long process even to deliver something small, but when the first one works. It's a relatively easier increment to add future results. So the next part is like earning trust on the ground. So you can't just like be an engineer just go and ask them to build stuff you have to like work with the **[16:06]** executives you need to work with the rest of the team to try and sort of understand what they want what that needs. So you pretty much, even though you're hired from let's say opening your Google , you are pretty much in this period, you should act as an employee for that company you need to understand their teams you need to actually work within that team to like make sure you get like with their trust and start implementing towards the KPIs that they care about. So it's important you have the right communication skills right kind of like sort of like interpersonal skills like get these things working. So there's all the, I would say, four habits that I've seen that's going to **[16:41]** like help you with this process. So be physical there as much as possible. If there's a possibility to like be on side, it's much more easy to consume information. If you look at like 40 per engineers in volunteer, like you actually go to vote like you were staying. I mean, not like frontline, but at least physically be there. So then you start demoing small and then like get a lot of feedbacks rather than waiting to build like an entire process and wait until end and the end to actually see something so fast iterations and also like other things like saying no. **[17:14]** So generally you get something I struggle with that as well like I say yes to everything, but it's not going to be practical if you say yes to everything. So because so there's a question panty, panty for deployed engineers, that's what if the means. So you're looking at scoping things like small as possible. So in that way, they're looking at delivering something meaningful rather than trying to absorb and solve everything. It's not going to work. And whenever something goes wrong, like sure that rather than trying to hide it **[17:50]** , because rather waiting until then like we need to like define like what sort of issues your system have their systems have, and like what sort of limitations that the integration might have like generally like try not to oversell. That's what I'm trying to say because you need to like be open about like what let's say if you're opening a 40 per engineer, what sort of limitations the model says things are hallucinations like the model capacity etc. All of these things needs to be sort of handled as much as possible. There's some like examples on the left hand side, like fortune 500 insurer company ran sanctioned pilot. **[18:29]** It was fancy. So I put the links to this at the end. So this MIT sort of like study sort of sort of found this, where at the end of the day, the integration that didn't work, and people started using their own sort of tools. So that's like one good example of this. AID plan is not working really well. And second one is that Morgan Stanley with OpenAI. So they had this like for the plane engineer concept. They have like people working within their teams actually deploy this and that sort of **[18:59]** resulted in like a really much better adoption. So I think like that's a good results for both sides, because there's time saving for Morgan Stanley and open a and they got a long term client for it. So some of the examples that came up from that research I would recommend reading that. So there's another one from OpenAI. So, OpenAI like actually went to the farm. And then they had to work with John Deere to actually try and like implement this was a really interesting case study as well, because when you work with the team, you actually see the problems rather than like doing things in abstract. **[19:30]** Generally, that's my recommendation as well, if you're doing consultant to work , this is like, but I'm better for you. And if the is very similar. All right, so something like some myths around this. It's not a rebranded as sales engineer, you actually write code that will actually work on the client side. It's consulting, it is not consultant generally recommend, not necessarily shape, even if you ship, it might not be integrated to the core product, you actually build things to the product itself. The hard part is a model. It is not the case. It is around the process and everything around that and understanding that building things are model is like **[20:06]** , let's say 20% of the problem, 80% like 70% is rest of the sort of ecosystem around that. You don't need a PhD. You just need to like have this like CTO mindset, who's like quite capable of with high agency, you sort of solve problems. PhD is good to like the model part, but the rest of it's pretty much around building things much faster, working with teams and sort of like making sure things deploy properly and you over communicate as much as possible. Like you go and tell like, what's working, what's not working, what you're going to deliver and deliver even before the deadlines is all of these things **[20:41]** are like bits that you need to avoid. So generally, like let's say, you know, like jump into like one of these roles, there are a bunch of stuff online to read about. This is like a summary of it. So some of them have lead code that I think like most of the interviews does not have lead code. They look at like practical coding skills, like how do you build RAG system, like LLM API, like how do you do the retry, how do you write the emails. All these like practical scenarios, like system design. So those are like the technical sides you get asked on. **[21:14]** And then you get this decomposition case anthropic is quite popular for that. Generally like a case study question that you get like you get a relatively abstract problem and then you need to like break it down, ask the right question, and then sort of like copy the solution with the right kind of process. And so another aspect is actually trying to like make sure that how do you make sure the system works properly. So these are things we discussed earlier about emails. **[21:45]** And you're looking at setting up things in a way, even if things fails, you should know. So like, let's say if you build like a RAG system, like how do you know if it's working, like you have like a metrics into track. Things like whether the entire system works, whether the extraction work, whether the generation works, the RAG system. So all of these needs to get checked. That's why it's important, like you define like what success looks like and define the metrics needed to improve that. So all of these needs to be like used earlier, but when you start building a few more, you see the patterns and then you can reuse the processes and the **[22:23]** checks and balances going going through. And these are the questions you get asked as well. So for my skills, my point of view, so most of the technical skills are covered in the program that you're doing, and J bootcamp. So the foundation will be shipping real endpoints, RAG systems, vector databases, HMS orchestration, multi-systems, sub-agent systems, sort of AI emails, and understanding agentic memory and deploying things, actually building things is the only way to learn this. There's no point like studying theory around this, even like notebooks wouldn't cut it. **[22:57]** So you need like more away from notebooks, how do you like deploy something, understand Docker, how do you like deploy something to Brenda, GCP, AWS, all of these things are needed so that you understand getting something out in the world. So not just AI concepts, but also like the deployments and how do you build something and deploy it. Apart from that, there's like some other soft skills that are needed. Like these are even though I say soft skills are like properly hard skill to learn. You need to like understand how you're looking at sort of like addressing ambiguous problems. How do you decompose that to actually like understand the requirements and **[23:31]** confidence solution doing onsite discovery, how do you do that. So sometimes this could be remote as well. I've seen like mix of both, given remote work is quite prominent right now, and I like, how do you like make sure you went with the team and then like sort of push something. And in enterprise, we all know it is not straightforward, not like a startup, you can like build things much faster, you have to deal with the processes and then try and like push stuff out. And yeah, so I think like when it comes to roll out patterns, like so like human in the low building like small automations and then trying to expand **[24:08]** beyond that. And then you actually like working with the client to actually do the handover and then train somebody in their team to actually take control of the agent or the process that you build is the best way that you can like actually handle things rather than giving just documentation and doing one demo, like you sort of like work with the team actually get it over the line so that you can mean they can maintain them long term, and you can sort of go and build another system with them. So that's the general outside process. But there's a bit of debate around like if FDs are like good for the company, **[24:45]** because there are some rumors around like anthropic trying to steal IP, especially like buying, but sort of like farmer companies, etc. This is a different debate, which I haven't like we really thought about like with side to take, but I understand the the risk that this kind of like if you have because you also bring in someone and like obviously there are like IP sharing that's happening for some reason if anthropic decided to build a competitive product. Yeah, there's a legal situation happening so that's like one side that we need to think about, but I think from from a job or a role point of view, this is **[25:22]** like a really good role that's a lot of people are like sort of hiring for. Yeah. So, so some sort of caveats apart from this, this might involve traveling . You're looking at 25 to 50% depending on the firm to travel, generally, because quite new career ladder is still a bit flatter still, but I'm sure like with time to also like go about and burnout is quite common. I think it comes from this like traveling and then like sort of like, yeah, probably is coming from working with external clients, but it is like, say like **[26:00]** , it's not all the time. And then you won't necessarily get straight away to create models and like this fancy stuff. You'll have to like work with the data plumbing and all the security aspects. It takes a bit of time to like get to building something quite cool. So you have to be comfortable with that. Yeah, so that's about the obviously check out the program that you're running. We're starting this week. It does have all the technical aspects needed for a role. And also we have like coffee cells to discuss like if you're going through an interview, like more than happy to guide you there on some of these **[26:34]** roles. So I'll post. Yeah, I saw some questions, but if you guys want to ask questions on me to yourself and ask, I'll pick the questions in the chat as well, while I 'm doing the So a long ago says, if we need core engineering skill deployment problem solving skills, yeah, pretty much. Yes. And also like, I would add a bit more like, I'll say client facing like skills like you need to like deal with clients and then like make sure these things get deployed. So I've seen like, so for example, Google does still check late code like **[27:12]** Google FD role. So they have read code, things around like traditional medium level lead code. That is there. But at the same time, you're looking at like, especially API design, Docker, et cetera. Frank has very curious how we did the slides best looking I have seen. This is Claude by the way, just from design. So I'm running actually, yeah, design by Claude and building through cursor. So if I flip to this side, this is the select that I'm creating. **[27:49]** I saw like an error here in the slide. I've just prompted it. Yeah. So, yeah. So. Hey, this is one question. Yeah. So in your experience for a three question, right. So are you dealing with mostly like local models or you mostly dealing with cloud or chat GPT because why this question is most companies are reluctant to share their information with the public cloud. **[28:20]** And they won't have like an on premises or in house a modern to the train. So what is it if you want. Yeah, I think so it depends. Right. So, for example, if the role, if the roles are pretty much hired by like lead, like sort of product companies, right. Motor providers or it could be, let's say, anthropic Google, they have something to sell rather than. So they might have open source model. They'll help you with that. But the idea is that you act as the extension to go and help them rather than. So if I'm a farmer company, I wouldn't get a forty per engineer. That doesn't **[28:54]** make sense in that case. I would get an engineer like to implement that like open source model. So, so the definition is that you have an engineer who goes into the client's site and build something. So whether it's the open source model, like for example, if it's open source project, yes, for sure. Like, for example, it's a misagents. So it's open source and you get like somebody like who can deploy that open source. And while doing that, yeah, for sure, you think about the different models, et cetera. But the idea is simple. Like you, you, you be this extension of a product company to go and actually implement their tools within that. So does that answer the question? **[29:28]** Yes. Yes. Pretty much. Yes. Thank you very much. Cool. All right. Sanjalia. So first person should become an engineer and then FTE. Yeah. I mean, yeah, for sure. I think it makes a lot of sense. You need to like properly understand the engineering to be a FTE. So we technical as much as possible. And then working with client projects, like actually like pick a client project that gives you the ability to try and build something and then like deal with clients like that's where it's very hard to like recreate that into experience **[30:02]** rather than doing that. Then you'll see like, okay, what does actually this coping step means? Like, what does this data engineering plumbing means? It's not just a word. It's actually like you have to like work with the teams like to get these things moving. And so that has like different teams and different communication styles. You need to like talk the lingo that different teams users and like when they are sort of like, so you'll see this like, like, socially IT departments. Like sometimes if you find an easy going person, it's pretty hard to work, but there are like people who are a bit hard to work with, could be there like over **[30:37]** worked. So it's very hard to get on top of their priority list to get something done. So you have to like actually like, yeah, be nice to people like work with them. And you don't have necessarily a lot of time to build a relationship because already they have had like a lot of time with the existing team and the existing demand coming from the team would have more prior to than you. So how do you do that? So you have to like be extra nice, like be really like over communicate and sort of like play a bit of politics. All of these things comes into play like me and I have to not just the technicals other things. **[31:08]** So it's like you wear multiple hats. So that's why I say like you have to be technical to defend yourself, but also you need to have a bit more senior experience like how to like deal with this. If you come from Google, open AI for sure, you have some leverage people like to listen to you, but let's say if you're like not Google, open AI and traffic, you probably need to like work a bit hard to like, like have some authority within those teams. So that's my sort of like take on this. So it depends on the firm that you work with. It's a question if I don't want to move into a specific role, but I want to use **[31:45]** that they. Yeah, in my day of the role, I mean, roles are not tech supporter. What's the question, Alish? So. Hi, this is Ali. I'm the one asking the question. Yeah, go for it. So just to be more specific, like, you know, like, like, I'm, you know, like in my previous role, I did kind of use AI, like, you know, like, you know, my previous role, I was a desktop engineer and I kind of was using AI, you know, to for like making, like, **[32:20]** PowerShell scripts or, or the ones I had making sure they work good. I guess what I'm, I mean, I guess what I'm trying to ask is if you say you don't necessarily want to move into an AI specific role, like the kinds of things you were talking about, but like, but I, but, but as I've been applying for jobs, you know, I'm from infrastruct ural to like, you know, desktop engineering roles, almost every job posting wants somebody who's, you know, not just AI literate, but like they want proof that, okay, you've used AI, whether it's from like, you know, creating a script **[32:55]** or, or, or using it. So I'm, I mean, I guess I'm just asking, like, you know, as I'm doing other certifications in my, that my job roles require like, how much should I go into the weeds in AI? I guess, you know, like, I guess, where should I find a balance? If that may, I don't know if that would question if I'm asking it the right way. You know, maybe I understand, like, so you try and, like, figure out, like how to upscale yourself in a way that it fits with this AI sort of demand, I guess. So, so, sweet much depends on, like, where in the target, like, but having this AI foundation there, it's going to help be helpful for any, like, sort of, like **[33:33]** , role that you're going to go for, whether it's like infrastructure play, whether it's like a F.D. general engineer, like, even like traditional software engineer, like, depending on what, what that role is. So, yeah, definitely, like, I would say, like, spend a bit of time understanding things like RAG, multi-agent systems, sub-agent, all of these stuff. This is not hard, like, but you need to, like, spend a bit of time building it. You just need, like, two to three months, focus time, and then you're really good. And then on top of that, you can slowly, like, do incremental learning on that. And after that, like, you pick some sort of infrastructure that you're going to focus on, like, for example, like, a lot of demand for, like, machine learning. **[34:10]** Like, training engineers, like, who can set up the infrastructure with AWS, GCP , Azure, whatever that is, you can make a play. And there's, like, there's lack of certified GCP engineers. I am trying to hire some people. It's very hard for me to find AWS. I think, like, there's still demand, and because the district, like, the market , still, it's massive for AWS, so it's also a safe bet. And I'm also seeing a casual, right, Microsoft Stack. So you can pick one of these and then, like, certify yourself, like, in whatever that interests you, and then, like, go to the interview. **[34:42]** So that's going to give you the infrastructure side of things, and then you have the AI knowledge. So I would take that approach to, like, try and, like, because practical skills value a lot, and having these certifications and the knowledge will help you, like, land your next role. All right, thank you. Okay, all right. I mean, reach out if there are other questions, yeah. So follow this path to obstacle and get prepared for the role. Seems a bit blurred, did. Yeah, so what you're looking at is, like, for example, depends on the role that you're going for. **[35:16]** If you're going for, like, general AI roles, AI player, engineer, engineer, engineer, you need to, like, be able to, like, build and deploy things. Because that's, that's the grandmother. Can you actually think about building, deploying something to production? Can you get, sort of, maintain that? So all of these aspects like CSC, Docker, all of these things are needed, but also important to understand how AI models work, and all of these things going to help you. So, for example, like, Google interviews, right, so they do check most of the time. Like, give you, like, a, this open-ended question. You need to, like, figure **[35:55]** out, like, what are the requirements, what are the, so, edge cases, and then, like, copy the system design. And after that, you need to, like, figure out, like, how are you going to evaluate the success, things like, yeah, emails, like, how do you put those things in? And, like, so, this is a whole, like, process that anything. So only way that you can actually answer those questions, rather than memorizing everything possible, it's just actually build stuff and, like, putting things out there. And, like, I have this concept called, like, building public. I get everybody to, like, if my courses like to build things in public and put it out there, you get, like, real feedback from people. It could be sometimes painful, but that's a faster way to learn, rather than you building stuff and just, like, studying your own, like, because that takes a lot of time. **[36:29]** So it's a, at least, like, build stuff and put it out there. If you can, like, build a quick app, open-source project, put it out there. That's going to carry a lot more value than you trying to, like, memorize 150 really good questions, still sometimes needed, but that's rather than that I would, like, build stuff. And I would hire somebody, like, who can build stuff much faster, rather than who's, like, really liking to, like, understanding, I don't know, like, just patterns and how to solve good problems. That's my sort of view on it. There's another question, what about focusing on a provider, or not, like, GCP, **[37:04]** AWS, etc., should we focus on one of them? Yeah, I would say, like, picking one of them is better, rather than trying to, like, learn everything at least first, like, because you have, like, 80%, like, shared, sort of, like, process between them. So if you, like, master one of them is very easy to, like, get across, and then , yeah, I would say pick one and master that as much as possible, rather than, like, picking random things. Yeah, I think that's my sort of take on it. It could be wrong, like, that's my view on it, like, I mean, on that I could be wrong as well. **[37:37]** But, yeah, I think I'd be best to, like, master something, and have this. So things like, cloud certifications are good, because they do cover, like, some of the latest architecture patterns, like, multi-agent, sub-agent systems. It's also interesting, and AWS has a machine learning certification. It's also interesting. I think they have now, like, an engineering one as well. This could be interesting, but it takes a lot of time. So you can start building just before you jump into it. All right, I'm just checking if there are more questions. Do you have recent JD for these with technical skills, BRS skills, and any **[38:23]** other that does not fit in about two? Is it, like, my previous slide, talking about Miho? Yeah, go for it. Yeah, hi, I think your previous slide talked about it, you know, normally what, but what puts it in the, you know, the LinkedIn or something, no, which gives you. **[38:56]** Okay, this is the background of the company. This is the work which we are doing. These are the skills expected. These are the behavioral skills expected. These are the additional knowledge or something which is expected and all those things. Some categories there. So I wanted to see this. This looks after 30 minutes. Initially, I was very excited, but later on, it feels like it's way, way tougher than what it is looking like. It is like, I'm not going to like sugarcoat it, right? **[39:30]** That's like, I mean, I can call it was in 30 minutes, but I'm going to say like somebody to become an like a 44 engineer. You do get like, I wouldn't say like, like quite tough, but you need to like be able to like, if you're technical already, like, yeah, you'll be fine. It's not like, like, for example, if I don't know your background, I would love to understand. I'm not a, I'm not a proper technical. I have very good hands on on the Oracle SQL and all those things, not recent times, but I'm working on a ZL delivery developer. That's totally fine. **[40:03]** Nothing like so because like with like a lot of these coding agents, like a lot of people now code, like, doesn't matter like their background is. And while you build stuff, you learn like, so that's the best to learn rather than like starting theories. It was a case like maybe two, three years ago, right now, like you've got cloud code, code X, whatever that is. And people with no technical background, like learn these things much faster. And you be in a, you be totally fine because you have technical knowledge. And so, yeah, to take two or three months, like actually like, get these things down, like the knowledge. **[40:34]** And then afterwards try and applying them. So I think like, so within your own firm, try to find these kind of like roles that you can like project that you can sort of like story lean into and then you get the real experience. So that's the way to handle this. So don't worry about like, don't get like faced off by looking at the syllabus. It's quite doable. So I would totally back you to like learn this stuff. So don't worry about it. Unfortunately, I'm in a situation where I'm actually looking for a job setting up a couple of more than a couple of months. Okay. **[41:05]** And I've been, I'm just going to be very open for fair with you. I've been joining some more than other modern lightning lessons to understand. Where do I fit? Where do I, you know, how do I try to map my skill and I can, you know, transfer my skills? Or it, I can easily switch into those. This is one of those things. I'm not necessarily, I'm targeting FD, but I'm trying to switch making a major pivot in my career kind of thing. **[41:39]** I hear, I hear. Yeah. So like to switch to FD, I think like the co-components are these, like try and understand like these aspects, like to be able to like build rack systems, build like agents, and then like things like memory. Like how do you like understand like loop engineering, et cetera, all of these things, which is you can learn within like one and a half months time, right? So that's the foundation that you need. So that when you have that foundation, you can go and apply to like, okay, if you have client experience, you go to FD. If you have product management experience, go to a product manager role. Or if you have like, for example, a bit more software engineering, like data **[42:16]** background, you can go to like AI engineering role. So, so you use this knowledge, plus like whatever you already had to find this role. So you might need to like learn a bit, like collect a few more like experiences could be a subset, like a certificate that would help your role, but like having like having this grounded knowledge, like it's quite like. So this is like learning, I would say coding, making like five, six, like 10 years ago, like understanding like, okay, I can I quote in Java Python like, so that's going to be a very versatile skill set to have. So that's my sort of take on it. **[42:49]** Okay. Yeah. Oh, do you, do you, do you think that, okay, this is another question, if you don't mind to answer this one. I'm totally getting confused with a number of people talking about use Claude and flavors of Claude, and somebody says use chat JPT or open AI products. And somebody says, no, go to Google's, Gemini and other things. Of course, Gemini have kept it aside, but out of these two being, see, as an **[43:24]** individual and paying, you know, 20 dollar per month, and not able to learn something out of it. It's going to be very costly for even though it is 20 dollar only. But what is your view on Claude versus open AI. I mean, this is not to influence anything. What is your choice? Yeah. So, I mean, I used to like use a lot of open AI before. Right now, I have a mix with in Claude code and cursor. So cursor provides like all the models you need. **[43:56]** Right? So, so that you get the open AI models, you get the Claude code models, like all of the models, so you can like use something like that. So, yeah, so that's the general sense. And they compete with each other, right? Like, so, like, I mean, let's come back, Codex and Claude code. In two months time, Codex, I mean, Codex getting very popular these days, it might surpass. The difference between these two is very minimal, like, I wouldn't say like very minimal. And there's a lot of marketing hype behind this, so just disregard that. So, stick to one of these and then you'll be fine. **[44:29]** Like, so there's Claude code with the Codex, stick to one of these and you'll be, if you need, you can go to open code, that's not another option. But what the skill you need to learn is like not these models, like the providers, what you need to learn is like how to use AI. Like, how to use AI coding tools in general, to actually quote, like, that's it , like, to be not faced off by the technical stuff. Not picking between open AI versus anthropic, because they'll compete, outcomp ete each other all the time. And they have like good engineers in both the teams and they'll figure it out. Like, if maybe they're maybe one month delay to get to the point, but get **[45:03]** comfortable with one of these and like stick to that. I mean, because it's not the option, like all these three are quite good, and you'll be fine, whatever you pick. You don't have to pick between, like, no need to have like, like, if you pick one, you lose. It's not the need to have in this one. If that helps. Yeah. Thank you. I'll let you listen and ask his question. Yeah, let's go for it. Yeah, very quick here. Thanks so much for doing this. And shortly I mentioned product management. I'm currently interviewing with a **[45:40]** couple of companies, mainly with the CPOs, right? I have a little bit of a hands-on experience as a PM now being building. Yeah. It is one phenomena right now talking about companies specifically here in Europe. I would go to an interview and technical one. There is a discussion about an AI native PM. What can you build? I even have a portfolio where I can show. But there is one thing that it's a little bit hard to pull off because even the CPOs, like traditional CPOs, they kind of want something, but they exactly don 't know what an in whom, right? If we want an AI native product manager that sort of decent that problem, right **[46:14]** ? And then when you go to an interview, the questions are so scattered and you're not linked. And it's very difficult sometimes to show the value you bring to the table. And when you get confused between traditional PM, should you now lean more towards AI and then you realize there is some knowledge gap, for example, on their end, that I'm afraid that they can misunderstand. It has happened one time. Okay. Was you, how would you approach in this situation where the knowledge is scattered? They don't know exactly what they want. How would you position yourself? Yeah, so I think like, so depends on the company. What I do is like, if I'm going to like a specific company and I'm going out heavily study the company, like what's the product they're building? **[46:48]** And I also like understand like what sort of value I can bring to the table on that regard. So whatever the demos I'm building, what are the skills that I'm putting on my CV? What I'm going to talk about the narrative that I'm going to have is focused towards like helping them sort of like understand that what, like how your skills are much more closer to what they're building. So in that way, it's a very relatively easy, like familiar for them to like figure out like, for example, if you're building like some sort of coding agent , like you can talk about like how you sort of do extensions to your coding agent. And like how about sort of skills you build all of these things. So all of these lingo is helpful for them. Like, so they might be talking about these **[47:23]** things all the time within their sort of organization. So that's going to help them. So like talking in that language is going to be helpful beyond like you. So, so the other angle is like, I would recommend it's like, you be that person that AI native PM, like whatever that is, I people use different terms. The idea is that you have the PM hat, like the core of it, but using leveraging AI to actually like help with like rest of the work that you're doing. Whether it's like, like researching about your clients, like building POCs, like, and like doing automations, all of these things going to help you like **[48:00]** sort of like be that person. So you slowly get closer to being an engineer. So in that way, like you, you are like quite good. So they can't deny that. Right. So you have the PM knowledge, you can actually build stuff and you understand like what sort of things work and what sort of things to work. Sort of like, that's my take on it. Those are two things I would do. But looking at your specific scenario, the interview, I can give a bit more advice there. Absolutely. I can tell you very shortly. So my next one is basically with the CPU and a founder. They told me they have a task. I'm like, sure what the task is, is like, yeah, we don't know yet, but it would be like, as follows, we give you an account on **[48:37]** cloud code. And we tell you something and you build for us live for one hour. Okay. Yep. And that's it. So, yeah. So something like that, it's very hard to like fake because you should be building every day to actually, because you then know like what sort of prompts to type, what sort of skills to use. All of these, how do you use plan mode? Like how do you switch between different models? All of these nuances. How about like, you know, one hour period. Like, so like, like, if something fails, like, how do you like revert like, like what, like, you put like the logs in, you connect some sort of like, sorry , you test it, right? **[49:10]** So for me, like, I have like one example, like, so you can like have a cloud extension, like to go through, like, to click through and get things working. I've connected MCP connection to my browser so that my cloud can actually talk to it, use property, all of these things going to be helpful, like beyond just like, just prompting to get something. So that's, that's, that's what they're looking for, only way to get over that face is like to build every day, sadly, like, it's just now like, studying that 's going to get you there, like, just be a person who builds every time. So like, obviously you mentioned you have portfolio, just extend them, like, **[49:43]** like, look at like how we can sort of like, maybe you're like, just one product that you focus on and just like continuously improve that. That's going to give you like, like, yeah, like, deploy a message and like, see what, what that works and how it works. So all of these things are quite nuanced. And the more you build, and this is the best time to build, right, where you have like all these tools, like build out, say, leverage that. Yeah. Sounds good. Thank you so much. Amazing. All right, guys, appreciate it. I'm going to jump off for another poll. I appreciate the question. Yeah. As usual, send me any messages if there are any questions. All right, guys. **[50:16]** Thank you very much, Turkey. Okay. Thank you. Thank you.