How To Get Hired For AI Agent Roles In Big Tech (2026) - w/ Sohil

In my career, I've never seen someone writing good code translating into better business outcomes. Meet Sohil Sha, PayPal AI engineer, ex Tik Tok, XJ JP Morgan. In this episode, Sohil shares with us exactly how big tech screams for AI roles in 2026, why lead code just refuses to die, and the real but sad reason you're not getting promoted. promoted. The hiring hasn't changed much. There's the same kind of lead code questions, uh technical rounds, behavior rounds, hiring manager rounds. Uh so there were like three or maybe four rounds of interview that I had to go to.

interview that I had to go to. How AI changed his actual day at PayPal and the trap it sets in your code. I think a majority of our code is written by LLM. I use it all the day. Um the things that they don't get is the edge cases. The 10x productivity myth in his own words. I don't think anyone has 10xed their productivity with just using LLMs. I don't see that. It maybe two times at max, maybe three in some scenarios.

max, maybe three in some scenarios. How he keeps getting promoted and switches industries successfully. People don't usually remember you for the work you have done. But people do remember the conversations, they remember the faces and that's just how the human psychology works. Please join me in welcoming soil sha to the ready set to podcast. Oh, and before I forget, he actually also shares what it was like to be inside Bite Dance during the impending Tik Tok ban. So, without any further ado, let's get into it. So, welcome. Hey, Nan. Hi. Nice meeting you.

Hey, Nan. Hi. Nice meeting you. Likewise, and really excited to deep dive into the really illustrious career you've had spanning JPMC. You were at Tik Tok for a while, now you're at PayPal. Of course, there's a lot to cover here. the where I want to kick off firstly is at your latest gig. So now currently you're working with AI agents over at PayPal. I want to kick off this conversation with going over what that hiring path in general looks like because I'm assuming probably when you were in the market when you were about to get hired at PayPal you would have obviously prepared for this type of role. Maybe you interviewed a few different places. So can you help set the stage for us in terms of where or

the stage for us in terms of where or what skill sets one needs to be hired in big tech AI agents roles as it pertains to maybe the year 2026. Okay. Okay. Um so when I started interviewing for these type of roles um I I would have to be honest and say that the hiring hasn't changed much. Okay. Um there's the same kind of lead code questions, technical rounds, behavior rounds, hiring manager rounds.

behavior rounds, hiring manager rounds. Uh so there were like three or maybe four rounds of interview that I had to go to and then um yeah eventually they came back to me uh with the job offer. I had a few other job offers during that same time. I was evaluating um between multiple different positions and then one thing I liked about this role was the um heavy use and engagement with AI which is exactly what I was looking for from my next role and that's one of the reasons that you know I decided to go ahead with it and accepted the job offer. offer. That makes total sense. I've had a few other you know machine learning engineers and data scientists on the show and the thing is um what they don't

show and the thing is um what they don't report and I guess a question that I get all the time from my audience is when you're being hired for something like you know like an AI agents role and then you when you're being asked to just solve lead code is there any component in lead code now that is more specific to AI agent type work or is it still what it was maybe like 5 years ago it's just like more, you know, algorithms based or more data structures type questions. Has has that changed at all or No, I don't think so. I think it's still the same. Um there are some companies that would optimize or try to uh you know optimize the questions that cannot be

optimize the questions that cannot be solved by LLM in some sense or they will try to figure out uh a problem statement that the LLM is not easily able to like provide a solution for that um in a specified given period of time where there are multiple approaches to the same problem and that can cause a problem when you're using LLM to answer those questions. Maybe in those sense yes some companies have optimized the question banks and reevaluated some of those things. Uh but other than that like the approach and the fundamentals of CS they haven't changed at all. You you are still expected to know a lot of those fundamental algorithms sorting uh decision trees all of those things are

decision trees all of those things are still stagnant. Um and that is going to continue as far as I can see. I don't see that going away anytime soon I guess. How do you feel about that given you've been in this industry for such a long time? Do you not feel that maybe because of the work that you're doing currently is so heavily leaning on AI? I mean, not to say that you're using AI to work, which might be the case, but you're working on AI agents. So shouldn't doesn't it make sense for the hiring to also check how good somebody is at orchestrating various agents like setting up workflows that can run autonomously handoffs between agents and all of those things. Do you not think

all of those things. Do you not think that makes sense? It would make sense but again like you have to think about the setup that you have for the interview. you only have 30 minutes to, you know, have a conversation with the interviewer and to assess the skill sets that the interviewee has. And within that short period of time, it's really hard to work on a real project. Um, actual evaluation might take a few months once a person comes in and then you have some time time to work on a project to evaluate their skill sets. Uh but given that the interview process process itself is extremely time boxed, the only best way to go ahead and assess someone's technical skills is still going to be lead code type questions and I don't see that going away. Yes. Uh the nature of work has changed. Uh you don't solve

work has changed. Uh you don't solve lead code questions on a daily basis and that is still relevant. I understand that concern and that feedback. But there isn't a better format that I've come across and that's one of the reasons why this is going to stay for a long time. Interesting. I can say and maybe you're already aware but this is a bit of a hot take because I keep seeing online and such where maybe it's like smaller scale companies not big tech so to speak but I know for a fact and maybe you can correct me if I'm wrong that there are now companies that rely more heavily on like they'll be like you can use whatever LLM you want, right? as long as you know here's the take-home problem,

you know here's the take-home problem, go solve this and then we'll talk through how you did that and that's like the actual interview. So, it's very interesting to hear your take around this and when when you say that this is still good like it still gets the job done and there isn't necessarily anything wrong with that which is not something you hear very often which and we love hot takes on this show so um just wanted to call that out. There are people who used to do like take-h home tests and the problem with take-h home tests is that u if you're in university it's okay to do those take-home tests cuz it's really timeconuming to do that and you have to take a lot of time out of your day and complete those tests and

of your day and complete those tests and again there is no guarantee on the next round if you complete the test. So for me as an experienced engineer I wouldn't be willing to spend that kind of time and commitment to doing those kind of tests. So I really want something that is time boxed. If it works out it's great. if it doesn't work out, let's move on to the next one. That's so insightful because I think this is where the differences in hiring at higher levels come into the picture, right? Because I think exactly what you just said. It would make probably a little bit more sense for a more early career/ early to middle career to have something like that. But I think you're spot on and it's not something I'd considered before where yeah like you cannot have people at already senior levels um grinding out 20 hours on like

levels um grinding out 20 hours on like a take-home assignment like it's you're not going to get the kind of caliber that you would want to attract which that's so cool and it's not something that I considered even though now that you say that it feels like you know it's just it just makes so much sense. Um, shifting gears a little bit, can you talk through just kind of a day in the life at your PayPal job? Right. So, obviously I understand you can't go too much into the project details, but just curious what your day looks like in terms of um like individual contribution work, maybe people management, meetings.

work, maybe people management, meetings. Just kind of paint the picture for us if you would please. Okay. Uh, so typically we have u agile teams that uh we everybody works in. So we have different pods and different projects that everybody is assigned to. So I'm a lead on one of the pods and basically day-to-day stuff is the same agile uh agile meetups. So we start with stand up. We have our twoe sprints. We go through the sprint planning all of those things. Uh we have our jur board go over all the things that are blocking us throughout the day. Address those concerns. make sure everyone who is blocked on things gets a pathway to getting those unblocked and focus on those initiatives. Um and then the other part

initiatives. Um and then the other part of it is writing uh code on a daily basis. So that's like 40 50% of time. So we are working on some green field projects. So since we are in the agentic AI framework initiative, most of the stuff is going to be green field which means everything has to be written from grounds up. There's nothing that we can leverage from existing systems. Of course, we need to integrate with those existing systems. So then we need to find pathways to integrating those back and forth getting the data from those systems and then making sense using LLM and other methodologies to expose that data across the org either outside to the customers or within the org or senior executives and different reporting and styles and so on and so

reporting and styles and so on and so forth. Um but yeah, that's that's the gist of it. Um and then obviously spend a lot of time on architecture, a lot of time on design docks, a lot of time on project management just to make sure that all the projects that we are focusing on are still meeting the deadlines and the timelines that are expected. expected. Um ensuring that there's uh enough coverage plan for for the team so that if someone is out of office or anything, we have enough bandwidth and knowledge to cover them. Um and then there's like a one week in a month where we someone is on a on call rotation. So during those on calls, we answer any queries, questions, any debugging issues that we need to figure out with our existing

need to figure out with our existing projects. Um, but yeah, I mean that's that's the gist of it. Yeah, I mean that sounds like a work week and a half if I can say that. What I guess I'm curious about is do you when you're managing team like you've mentioned that you were the lead, do you see a lot of telltale signs of folks on your team using LLMs to write code? Is that something that you do yourself? I guess just curious for your cuz you know how like I know at least at my org there's there's like people are either for it or they're against it. I don't think there's a lot of people that are lukewarm about utilizing you know AI for writing code and such. But obviously I don't work at

and such. But obviously I don't work at a big tech organization. So I am curious what's like the culture for lack of a better word and I know it changes from individual to individual but yeah where does your team stand where there's like what do you sniff on you know like a monthly slashquarterly basis around perception with utilization of um AI tools for actually writing slash debugging slash testing of actual real production code I think I think a majority of our code is written by LLM I use it all today and I do encourage everyone on our team to be using it every single day and that's the direction that we are going in and it's going to continue for some time until the models become better

some time until the models become better and they can do uh additional tasks on their own then that would be great. Um I can give you some examples like apart from just yeah apart from just writing code uh we also have some skills and the skills is like a skills.mmd file which has an end to test cases and basically just automates our entire testing process which used to take half a day or one day to go through the entire regression testing before we release anything out.

testing before we release anything out. So the amount of time that saves us is tremendous. it frees up our bandwidth in terms of doing things and I would encourage everyone on my team to be using it. Um, for someone, you know, not using it or absolutely against it, it's totally fine as long as they're not dropping the ball or they're not able to catch up on the pace and and the way things are happening. Uh, it's totally fine by me if they don't want to use it.

fine by me if they don't want to use it. But again, I would always encourage everyone to be using LLM, getting that assistance to making sure there are no bugs or issues in the code. Um also uh LLM can generate code but it can generate a lot of code which is a lot of boilerplate code a lot of lines of code. So yes again um it can help you with writing code but you still have to be the reviewer. You still have to prompt prompt the agent to do the right things and those things stand uh standard. So what I've seen is that um lot of the entry- level senior engineers they used to write a lot of code in the past and

to write a lot of code in the past and then the staff level and principal level engineers they would be the ones reviewing it and uh there used to be like a uh majority of the review was done by staff and principal level engineers majority of the writing was done by the senior and the software engineer level entry- level jobs that has kind of shifted a lot of people have now become reviewers the writing code is done by LLM M staff and the senior engineers, they're doing the reviewing of the LLM code. The senior staff staff and the uh principal engineers, they're now more into the architecture side of things, designing the systems, making sure they have a broader understanding of how systems work. That's so cool. So this is actually another question that I get a lot and I never know what to say

get a lot and I never know what to say but because you've been you utilizing um you know AI for writing code for probably a while now can you maybe speak to um any of like the pitfalls that you've seen that are easy to fall into that you know as you said you already mentioned one of them which was that it rides just a lot of volume right which can sometimes be a bad thing maybe slightly annoying But for other you know like because a lot of my audience is you know mid-career folks in a lot of big tech companies. What are some warnings that you can give in terms of folks that are just now starting to adopt these tools and are probably not as experienced or

and are probably not as experienced or you know or they they don't really have as much wisdom as you do because you've just been around for so much longer. So have you seen anything in your experience that you maybe fell trapped to or that but you would also like to warn others against? Um so one thing I think LLMs are good at is following the coding standards. So if you mention the coding standards in the agents.mmd file I think they get it spot on nine out of 10 times. Um the things that they don't get is the edge cases.

that they don't get is the edge cases. So there are specific business logics and that's where your business would be making money on it and those specific edge cases those specific business rules that you have put in place which are extremely customized the LLM is not trained to know any of those things and when you try to optimize or make some code changes it's more than more likely than not it's not going to be able to figure out where that edge case is and then you have to as a engineer reviewing the code you need to make sure those edge cases are covered um those configurations uh are being managed properly and things like that. So that is that is a very specific domain knowledge which you need as an engineer which you just cannot put it inside the context for the LLM to understand.

context for the LLM to understand. So I guess just because this is not entirely clear to me. So what if in as as a part of your skill MD you have all of these business rules/ edge cases very clearly documented. you you're like the classic make sure you follow these do not make mistakes you do all that and then you that it still sometimes just misses through for lack of I guess it's too much context for it is is that what's going on yes yes so if you have like a finite number of those rules like let's say one or two maybe then it's fine it would still get it but let's say those that list of you know must do must do must do gets into like tens and hundreds

gets into like tens and hundreds then you have a problem cuz the agent it doesn't know anything about it. The LLM is like okay I covered nine of the 10 and I think the rest of them is good and then it tries to hallucinate after a point point cuz it is running out of tokens it cannot you know process everything as quickly as it can and then it needs to give a response back. That makes total sense. I guess from here what I'm curious about next is if you, you know, dial the clock back a couple years um maybe 3 years when you were in Tik Tok or bike dance. Um I guess can you help

or bike dance. Um I guess can you help contrast just you know we just went over a day in the life now apart from obviously the obvious things which is that you're writing probably 10x faster code in terms of not just writing but testing and all of that. So at least my assumption here is that speed is something that has you know just drastically changed. So first of all maybe you can comment on whether that assumption is right and then as you do that if you can also share maybe some other meta level things in terms of how what stuff has changed like maybe you used to be feel more into the weeds of the problems that you were solving that you just don't anymore because you're more concerned with architecture. you have like a more higher, you know, like

have like a more higher, you know, like 30,000 ft view versus maybe before you didn't have the opportunity to do that. Like you had to write the code or at least oversee somebody else that wrote code. So, can you help contrast that for us as somebody that seen the shift in real time from their desk? Yeah. Um, compared to the pre LLM era, it used to be really hard to contribute to an existing project. So uh as an example like WebRTC was an established product at by dance and when I joined the team um we were supposed to um basically make WebRTC protocol and web uh bite dance compliant for users data and that was the task at hand and we had to sift through all the architecture figure out what protocols what codecs everything that is being used um uh and

everything that is being used um uh and figure out a plan on how to make those compliant And for me coming in uh it was really hard for me to figure out all the blocks and pieces that have been written in because most of the code was custom code and there's no official documentation. Uh most of the documentation was team driven. Um and then there's different orgs that you have to communicate with to get the information that you need. And it used to always be hard to contribute to those kind of projects cuz those are large initiatives, extremely complex technical problems and then you want to fit something into it which is going to impact everyone at a global scale and it becomes really hard when you're

and it becomes really hard when you're doing that because if you make a if there is a downtime everyone loses um uh access to Tik Tok or features that we're publishing and then that is a massive outage. So you have to like double test, triple test everything that you're doing before you release it out. Having said that, now that you have LM LLM in place, I can ask LLM to look at the codebase and give me a summary of what the code flow looks like, what the architecture looks like. It can give me like a really good highle overview of what the codebase looks like, which used to take me like three months to six months to get familiarized with code base.

get familiarized with code base. Now I can do all of that from day one. I have all the information I need. I can optimize based on that and I can figure out the plan of action and then create design docs get attributed bymemes who need to be involved and it's much more productive for them to be involved in the view process rather than just transferring knowledge over and over again to someone some individual or training them for 6 months 3 months. So I actually had a target senior data scientist on the show just about a couple weeks ago and something she said is coming to mind right now uh hearing what you just said which was that on paper it would appear in you know just theoretically that if each employee in an organization 10x's or we'll even

in an organization 10x's or we'll even say conservatively 20xes their output because of this shift that you just described described You would see on an organizational level the productivity increase would literally it should be exponential right just in terms of how math works I guess however that has not happened and I guess her thinking was and what she was you know getting to was the fact that when you unlock such an extreme amount of productivity gains it becomes a challenge for teams to then coordinate amongst themselves to continue as an organization or as a team to also sustain that 20x growth like you start getting on other people's toes and there's like double work sometimes and not all of it directly translates. So if I present that I guess take in front of

I present that I guess take in front of you what how do you see that? How do you how has that unfold in your uh viewpoint? Um I mean honestly I don't think anyone has 10xed their productivity with just using LLMs. I don't I don't see that. Um it's maybe two times at max. Uh maybe three in some scenarios but I don't I don't see any productivity gains beyond that. Um Um sorry if I can quickly jump in. You just said it would take you 6 months to read a codebase. Now it takes you like two hours. So I know you're doing a lot more than just reading code bases but you know it feels like it should be more than 2x no like that's just you know a

than 2x no like that's just you know a question question that's just the initial phase right after that when you have to actually get into the codebase make some code changes and actually deliver value when you have to do that it doesn't help you a whole lot because you need to prompt it a lot you need to review the code and do all of those steps steps and you need to review a lot more code than you used to before cuz previously if you were theme on the project, you would make a line change and it would work in production. But now that you have an LLM, it's not going to make that line change. It's going to take care of all the edge cases. It's going to pressure test all the scenarios and then

pressure test all the scenarios and then give you like a 100 line output. Then you need to review and then make sure it it is optimized and everything for you to push that to production and it's maintainable at the same time. Um but yeah, going back to the question, um I don't I don't see in terms of business value being 2x or 3x um any even uh anytime soon. I think it's going to take some time until we get there.

some time until we get there. Um what I do see is the quality of output growing higher and that means the products that we are developing, they are going to be more refined, more finished. um there will be less bugs, less tech depth and those kind of things will go down drastically. Um but if you think about it, tech depth is only like 20% of an organization at max. max. In best case scenario, some cases is just five or even zero.

just five or even zero. Um so yeah, those are things I think that will be reduced going forward like you'll have less tech depth, easier to uh figure those things out. But any kind of new product development, those kind of initiatives are still going to be roughly be the same. I don't see any massive changes um or enhancements happening anytime soon. I think the most interesting thing that I'm taking away from this is um more higher quality output, lesser bugs don't directly translate to business value, which is very interesting. Um, and it's not something I'd considered before, but it makes sense, right? Because it's just a small, maybe not a small, but it's just a part of what drives revenue. It's not like it's not a magic switch where if you just increase the quality of the code,

just increase the quality of the code, suddenly you're just magically making more money. Honestly, like in my career, I've never seen someone writing good code translating into better business outcomes. Has never happened. I've never seen it. Okay. Every time you have to push something in production, it has to be on a tight deadline because there is a customer waiting on the other side who wants to use something. It is never going to be perfect, but you just need to ship something out so that they can use it. And that what that is something that drives the revenue. It's not the fact that you produce code that is free of bugs or errorree or is maintainable and all of those things. Those things are important for the long run as you onboard more customers, but it's not necessarily going to drive the business back.

back. So cool, man. like yeah I I'm just blown away by I know for you probably this is like a normy observation but this yeah it's so interesting that I had never once thought about this that yeah if you make bugs disappear you don't make more money the user is the user there you know their ogre brain is still scrolling just the same they probably don't even realize that something loaded like 20 milliseconds faster that an entire team of 50 people had worked six months to get to those gains. Yes. And this is this is a secret ingredient for someone trying to move from senior engineer to the next level.

from senior engineer to the next level. Uh this is what makes you a better engineer. Uh is not to write is not to cover all the edge cases and make the most perfect piece of code is to make sure you deliver business value at the end of it and then the more value you deliver the better you will be. I'm not advocating for the fact that you need to just keep pushing whatever you write to production. That's not what I'm saying.

production. That's not what I'm saying. You need to make sure the coding standards and the quality are still set high. And as a, you know, senior engineer and even above that, you have to set that bar really high. But again, you need to deliver business value. That's the first priority. Yeah. And speaking of business value, I think you alluded to this earlier where you mentioned that you were at Bidance at a time where the whole, you know, uh, US government versus by dance thing was going on. And I think my read was that you were at least indirectly maybe directly but at least indirectly involved with making sure that Tik Tok would be around in the US. Is that right? Is that something that you worked on directly or indirectly?

on directly or indirectly? Yeah, in some sense. I mean we were part of that initiative. Um and we were trying to make sure that the web RTC protocol was compliant for US users data and that the US users data was secured on the US soil which is the objective of the project Texas initiative that was started at Tik Tok. So everyone in the company was working towards that initiative. So that was a big focus uh during that time. Yep.

during that time. Yep. So when you're at an organization that's like going through the ringer like by dance was at the time. How can you describe just kind of the vibes from inside the office? Are people just like on edge? Is everybody just like freaking out? Oh my gosh, what is going on? It's like, you know, war room type thing that they show in the movies or is it just more like, hey, we'll just do our job.

more like, hey, we'll just do our job. We'll do our best and we'll see what happens. happens. Um, in some sense, it's a it's a two-way street like the war rooms. Um, there used to be discussions. Um there used to be timesensitive things um and you know we used to freak out uh we didn't know how things are going to pan out if you're going to have a job tomorrow or not. So those things obviously happen um but overall I think everyone in the organization was razor focused on their initiatives. initiatives. um there was less chatter and I think there was a strategy around uh what's going to happen and you know trying to create panic situations and they were all focused on specific initiatives and tasks and ensuring that if we accomplish

tasks and ensuring that if we accomplish this task then uh you know nothing would happen and everything would be great. Um so that was how the company just rolled and everyone in the company would be focusing on those things and it was a razor focused company. Um I really enjoyed my time there and you know I'm I'm happy that we got to the point where we got to today. Yeah. And I think from your journey it also sounded like Tik Tok or by dance was where you had kind of made a shift in your career at least from your LinkedIn it sounded like you were more of more into finance up until then and then you kind of pivoted more into tech.

then you kind of pivoted more into tech. So can you talk us through what that was like at the time because obviously like the entire skill set is different. So maybe take us through like a like a month of prep in terms of what somebody needs to do that is trying now in today's day and age maybe to break into or pivot into a more tech heavy role from we'll just say like a tech adjacent role. role. Um so for me in my specific scenario I was uh still heavily on the technical side as my role at JP Morgan Chase. Um yes in the later half of the career over there it became more of a manager tech lead kind of a role. I was managing a

lead kind of a role. I was managing a team of engineers and then regular interactions with the product owners and things like that. And that had its own fatigue and that was one of the reasons why I wanted to hop back into the individual contributor role and just uh focus on the technical side of things um and let you know some other person take care of the uh noise within the organization. So um but yeah I mean for me it was not a big change in terms of roles or anything like that. Yes the industry is different. So I moved from fintech uh where I was processing billions of dollars in payments to now processing billions of bytes of streams.

billions of bytes of streams. And obviously both the challenges are different. On one side you need to make sure none of the transactions are failing. Um on the other side you need to make sure you have a superior uh service quality compared to your competitors and um in some sense they kind of align as well in terms of technical responsibilities and what do you expect out of the system but then in other sense in the business terms of it it's a completely different business model. So obviously u I had the pleasure of learning how both ends of the spectrum work. So from this side I learned a lot about finance. I learned a lot about payments and then coming into bite dance I had no prior experience with audio or video processing. So once I got into the role that was the first

I got into the role that was the first thing I did and you know I learned a lot on the fly uh while I was working at bite dance and um it was a great opportunity. I I couldn't say no not that I was looking for something specific but when it came uh when this opportunity came across I couldn't say no. So I had to I had just went ahead with it. Yeah. And so did is this something that came up during your interviews and such where they were like we need somebody that has audio video experience or they were more so betting on the fact and checking obviously whether you have the chops to pick it up on the fly which of course as we know you ended up doing and yeah

and yeah I think they already had themes uh pretty much for their pieces. Uh so they weren't specifically looking for someone who was an expertise. They were looking for someone you know who could you know quickly pick things up on lay one and then hit the ground running and then help them accomplish the task that they had in hand. And that was the focus uh at least that's what I felt during the interview process. That's what they were looking at cuz obviously I did not have any prior experience with WebRTC, right? right? Um but yeah, I mean that that was that is something that they were looking for.

is something that they were looking for. I'm happy things worked out and I think in most big tech companies that is typically the approach. They won't look for specific roles or specific skill sets as long as you have the you show the right aptitude and you have the appetite to learn more. I think that's more than enough. Amazing. And then taking another step further back into your journey through JPMC obviously you saw a few promotions while you were there. So for those in our audience that are in you know early/ early to midcareer roles what would you recommend for them in terms of strategies to get promoted faster? Of course we understand that you know you have to be um you need to make your presence known slash you need to be seen by leadership because ultimately they are the ones

because ultimately they are the ones that make those decisions. Obviously there's no substitute for hard work. you need to deliver the work. But outside of I guess those or some of the more you know like obvious type uh notions around this, what are some things maybe that people miss out or don't focus on enough that plays a decently big enough part when it comes to getting promoted?

when it comes to getting promoted? Um I think u I think obviously you need to be hardworking. You need to make sure your business objectives are accomplished. That's that's a baseline. Mhm. Mhm. Okay. That's where you start and then you need to start differentiating yourself from the others that are at the same level or the level that you're trying to get accomplished or you know promoted to and things that you can do to get there is try to ask for recognition. um maybe some awards within the company or maybe external recognition. Uh try to speak at conferences and things like that just to you know validate your thoughts, validate your expertise within the field and the specific domain and then um try to go from there. That's that's

to go from there. That's that's something that people notice. Um it's really like as an engineer I know it's really hard and I'm an introvert myself. It's really hard for me to like step away from my desk and go and talk to people. I really don't like that part of my job. And I'll be very honest about it. But you got to do it. You got to, you know, get out of your comfort zone. Um, you know, do the attend those networking events, meet the senior leaders, uh, try to communicate with them. People don't usually remember you for the work you have done. But people do remember the conversations. They remember the faces.

conversations. They remember the faces. And that's just how the human psychology works. They don't remember, you know, a line item in a PowerPoint presentation. They just won't. Okay? No matter how how big the highlight is or how big the font is, at the end of the day, they wouldn't know you. For for them to know you, the only way for them to associate your name with your face is for them to see you somewhere. And that's exactly what you need to do. You need to work on your visibility part of it at the same time.

visibility part of it at the same time. And once you combine all of these things together, you know, that's something that will, you know, place you nicely in your promotion bracket. The other thing is like a lot of people think um you know it's a lot has to do with your direct manager trying to pitch you for promotion but just for a second if you reverse that thought a lot of it has to come from you. If you help them build a case and if you make it easier for them to build a case for you to be getting promoted they would be more than happy and more than willing to do that rather than having to work 10 times hard on some other candidate. So

times hard on some other candidate. So if you you have to differentiate yourself from the other guys in the group for you to stand out and uh you all everyone is part of the team. It's not it's a healthy competition. It's nothing like uh you need to compete with someone else or put them down or anything like that. But you need to like create a brand for yourself which is different from the ones that are there in the team and then make it easier for you know within your org or within your u with your immediate managers to recognize you. Yeah, I love that you make it almost sound relative, right?

make it almost sound relative, right? Like there is no objective bar here. You just have to be uh above the other folks on your team, which I like that because it immediately sets a target that anyone can follow versus being like you need to do X amount of Y, you know, C amount of Z and which then becomes like a whole different different relative in different orgs. Those can be relative. um like I know there were certain expectations when I were a JPMC but those were not the expectations when I moved into Pance or PayPal for that matter. So those are all relative to the organization the business objectives and the OKRs that they're following and you just need to figure out how you fall in

just need to figure out how you fall in line and get into those priorities. Yeah. Yeah. Yeah. No, that's really cool. And I think going now further back from where we were would lead to a disservice for both you and our audience. So that is I guess in terms of history at least as far as I would like to go. However, what where I do want to go next is I'm curious because you're somebody that like literally does this for a living.

like literally does this for a living. Where do you stand in terms of like the AI doomsday/ rage baiting hype cycle that goes on? Right. So I feel like the internet now is firmly divided into two camps. One AI is going to just replace everybody and anybody. it doesn't matter who you are, what you do, you're done. Unless you obviously you're like a plumber, in which case you're, you know, good forever. forever. And the other side says that no, it's a bubble. It's made up. It's only good for making Giblly art and that's about it.

making Giblly art and that's about it. It's not exactly super useful out obviously outside of folks whose day job is to write code because I don't think anybody can, you know, argue with that anymore. At least anybody, you know, with a fully functioning brain. But as far as the masses go, where do you see this all going? And part of my reason for liking to ask this question is I like to this it's this like a thing that I do where I enjoy time capsule elements of things, right? So it would be fun to come back to this like 3 years from now and watch me ask this question and watch you answer whatever you're about to and then just smirk at the absurdity of how

then just smirk at the absurdity of how it all went down. Maybe you were bang on, maybe you were completely way off, maybe somewhere in the middle. But I like to plant these seeds now so that I can come back to these like years later. So if you will please humor me. Sure. Uh so my honest take is um that you're going to see a combination of all things happening at the same time.

things happening at the same time. And what I mean by that is there's going to be AI optimist, AI pessimist, and then AI middleground folks. And all of that is going to progress at the same time and different job roles will see evolution due to AI in different um if different speeds and different mechanisms and how they do things. So as an example right like as a software engineer I totally see myself managing a group of AI agents in the future. Okay I don't think I will be writing code as much as I do today. It's it has already reduced a lot and it's going to reduce a lot more. A lot of my work is going to

lot more. A lot of my work is going to be instructing and prompting these AI agents to be doing the work that I'm doing right now. And that's exactly what is going to happen in the future. It's going to happen. It's happening. The other part of the question is okay, we only see chart GPT or some other AI tool just doing Gibli art. Well, yes, that's the P. If you can do that at a global scale and if you can do other PC's and other proof of concepts showing that AI can solve a business problem, it's just a matter of time before they scale it at the global level. The reason you don't see it right now is because maybe there is a constraint in terms of either the

is a constraint in terms of either the infrastructure or the software frameworks that need to be built before we can do it at a scale and that hasn't happened yet. It's it's a work in progress. It's going to happen continually as we progress through it and then once it happens it's going to be there for everyone. I can see within our organization already there is a lot of uh critical tasks being done by AI.

of uh critical tasks being done by AI. There's a lot of admin human in the loop approvals those are all being done and handled by AI. So there's a lot of automation in place and reduction of human interventions or human processes which would putting delays in terms of days and weeks going down to bare minimum of minutes. So those things are happening. It's going to continue to happen for your specific roles for your own business initiatives and those things will continue to evolve. Having said that uh there was an evolution that happened from mainframe to distributed systems and we were in the same conundrum back then and everyone said you know what this is not something that can work distributed systems always go down they are very fault toler they're not fall tolerant compared to the

not fall tolerant compared to the mainframe systems and then on the other side the distributed developers like you know what mainframe is for old guys they are never going to be able to scale up to the needs or you know be able to operate at a global level like we do and you know the funny thing is majority of the banking operation still works on mainframe although the interfaces are now built on distributed systems um yeah you know it's really amazing to see how things have evolved and I think both of those spectrums have survived over time so I think it's the same thing that's going to happen with AI you just have a new interface to work with you have

new interface to work with you have better quality of uh services that you can offer to your customers and wherever that opport opportunity comes in, you will be leveraging it and using it to do that. And then in other sense, in other business areas, you would just be BAU doing the same things that you're doing as of today. Huh. Wow. I think Yeah, I think I'm going to need a minute to digest what you just said. And I guess the reason I say that is yeah, it's not a take that you hear very often. And and I like that it's so nuanced, right? I feel like you covered so many pillars just now based on what you just said which literally I'm noodling on it in

which literally I'm noodling on it in the back of my mind right now but like I said I think it will be fun to you know come back and see and obviously I need to do some more reflection just because candidly right um I use these tools a lot like I do a lot of agent orchestration and such of course it's not you know even onetenth as technical, probably 100 if we're being honest. Um, as technical as some of the constraints that you're working with in terms of what needs to be done, drive business value, blah blah. I'm just one guy that's trying to run an internet company, if we can even call it that. and already, but I guess what I'm what I'm getting at is already I've seen back in 2024 of April when I first

back in 2024 of April when I first started the show versus now my output and my time spent doing those things have literally shot up in opposite directions. It's just unbelievable for me to have gone through that change. So it's always interesting slash it it makes me really curious to ask that same experience for folks in the on the other side of the table when it comes to like their day jobs and such because as as far as I'm concerned my day job hasn't had too much of AI infiltration yet.

had too much of AI infiltration yet. That is something that's happening right now. So yeah, I mean this was so cool and you know I feel like I'm yeah my brain probably like grew two inches just in this past hour talking to you. So I really appreciate you, you know, breaking down these super technical heavy terms slash discussions in in a way that um that not only could I follow along because I did I'm sure my audience which is way smarter than me will definitely also be able to follow along.

definitely also be able to follow along. And I think that speaks to the for me that's an expert, right? like somebody that can talk through the stuff in a non-jargonheavy manner in a way that you could probably explain to an 8-year-old. And it's just rare to find that. And often times I'll begin this conversation with people similar to how we began. But then I'll just have to pivot cuz I don't know what the hell they're saying and it's just hard to keep up. So yeah, sorry long- winded uh rant to just say that I think you're really cool. I think you're really smart and I really appreciate you taking the time to talk with us here today and it means a lot to us. us. Thanks someone for those kind words. Uh

Thanks someone for those kind words. Uh and I'm sure that whatever uh we get out of this podcast is going to help someone around the community around the world and hopefully there's some value being generated out of it. Awesome.