Latest / The Unfiltered Engineer / Ep 9: Think How It Breaks feat. Rajakumaran Gowthaman

Transcript

Ep 9: Think How It Breaks feat. Rajakumaran Gowthaman · The Unfiltered Engineer

• Vishakha Motwani: Hello and welcome to the Unfiltered Engineer. My guest today is Rajskumaran Gowathaman Raj is a principal engineer in cloud security at Palo Alto Networks, where he spent nearly five years moving from senior QA engineer to principal. Before that, he built his foundation in QA and test automation at Cisco and Avaya. Today we are talking about his path from QA into principal engineering and what testing taught him that shaped how he thinks about security today. Welcome, Raj. Tell us where you're tuning in from. Raj: Hey Vishaka, thanks for having me here and I'm very excited. This is my first podcast and I'm more excited than you are. So I'm from the Bay area and I've been here since 2017. I work in Palo Alto Networks, like you mentioned. I work as Vishakha Motwani: Mm. Raj: a principal engineer and yeah. Vishakha Motwani: I'm excited to have you here. That's it's been a while and Raj: Thank you. Vishakha Motwani: for people listening, we did our internship Raj: You Vishakha Motwani: together. We are from Northeastern University and I connected with him during an internship. but today like I have seen his journey through his career, and I could see his work. he's very passionate about in doing the things that you do. So I'll dive right into our first question that I because of which I brought you here my personal interest was you went from QA and test automation to principal engineer in cloud security. What did that transition actually require and what did QA teach you that a straight engineering path wouldn't have? Raj: So the way I see it, so I'm still in quality. If I'm not like I moved from QA to principal and these are two different roles. So I'm still with the quality engineering and the principal engineer is just a role or title and the scope of what we are doing in our engineering team, right? So it's just the change of the title and role, but I'm still connected to the quality. engineering, just that if you see at the start, I think we you mentioned about us doing our internship in our firm networks, right? So that's the play. Actually, I wanted to come in as a network engineer, but that internship kind of changed my change, change what I wanted to do after I graduate. So quality engineering was something like I looked at as like a very you kind of do things a little bit faster, like the automation aspect, the way you test it, the way you try to break the system. These are some aspects which I thought was really interesting. And that's why I wanted to pursue it as a career starting from our internship. So after that, think my initial years were more on you definitely need a good mentor. You need to go have a good manager or mentor to actually guide you to the right, how you want to go or how you want to transition in your career, right? But if you don't have them, I think it's a hard path you fail and try, fail and try and get to where you are. So for me, it was a fail and try. I didn't have a good mentor or someone to guide me through this, but you kind of at that point, I was looking at more of writing test cases, writing automation and finding issues. It was more specific to that. particular product and the feature that I was testing. But, I think that the way I was thinking also backfired when I was in my initial career. So later I started expanding my scope of thinking it in the product aspect, like how the product is, how the architecture is, how the system design is, how we are deploying it to the end to end customers, how it is going to be. how it is going to create an impact to the customer when it goes to production and things like that. So once you broaden the scope and not restrict yourself to just testing, right? Vishakha Motwani: I love that your thinking is more systems thinking, Like where when Raj: Yeah, yeah. Vishakha Motwani: and it happens to everybody, I feel like when you start new in your career you're very focused on the job that's given to you and you kind of Get fixated on like, okay, is my job just writing the test cases or is my job just testing that feature that goes out? but you also said that you're broadening the scope, which makes so much sense in that you're looking at user journeys, where they start, where they end, are they dealing with any issues in between? But to kind of go in a slightly different direction is how do you work in cloud security, like what does that workflow would look like in your day to day and how do you implement your QA principles to that to cloud security aspect? Raj: Yeah. So, let me answer. let me quickly answer that, the, development, the state engineering path question, right? I think I missed that. So what it taught me then what development then, would have taught me is like, are certain things that when you are a developer, you kind of look at that particular aspect of the creature. And, this is my understanding. I might be wrong as well, but, you kind of make sure that you think in the aspect of how things it might, how to make it work. But when the way I look at it is like, how do you kind of break that system? When you do a system design itself, you kind of think in the aspects of how it is going to break. Because there are a lot of components that a developer might not be aware or he might not be because he's very focused on that particular feature or that particular module is working on. But when we come in, we kind of look at in a holistic way. We look at, look how it is going to be deployed. What are the different components that is going to affect this? That is one aspect that QA taught me and it's still teaching me. I'm still in the learning phase. So it taught me. coming to what coming, coming to very specific to cloud security is that now everything, now it's more of a SaaS product that I'm testing, right? And you're testing a product in a very complicated environment. You will never know. You can really not kind of isolate a failure. Okay. It is happening only here, right? It is like it can happen anywhere and you don't know where it is going to break. things, so you're kind of testing something like a very calm in your, you're kind of testing it in a very complicated environment. That's all I would say with the, with whatever we are deploying. think most of the process products are. kind of like that. And the way I see it now with very specific to our whatever I'm doing is like it's more on the cloud. You kind of learn more on distributed systems, microservices and databases and the Kubernetes pods that are that are running, which is like hosting your services and things like that. It's like a stitch complicated environment. So how we come in is like, we kind of, we kind of need to write all these, not only, not only about testing the feature, right? We need to have the right infrastructure that needs to test all these scenarios. Right. It's not, it's not easy. right now, when, when something, when a feature comes to us, it's not about us testing, testing only that feature in just one, in one aspect. For example, we have a lot of cloud deployments like AWS, GCP and things like that. have on-prem and, and our solutions run on VMware, KVM and things. There are a lot of environment and right now the product that we are testing in is like. It's more of a cloud product, very specific to customers. It's a cloud managed product. So when we go, how the upgrades happen, how do we upgrade the customers, how the upgrade shouldn't affect when we roll out the feature to the customer, right? It shouldn't break anything that is working for them. And if there is any issue that triggers once we roll out, we need to have a hot fix immediately. And we need to make sure that pipeline, the pipelines that we have are so fast enough to detect all these issues even before deploying to the customers. So when you see from the QA aspect, from the QA aspect, it's not only about your, not only about testing your feature, writing automation, things like that, right? You need to worry about how the, you need to worry about the CACD pipeline, how it is, how it is brought, how do we, how we have error detection before we, before we deploy it to the customer. how many environments that we are setting about these environments are production ready. Like are they related to what the production is currently running. So it's more on how you think, how you deploy to the end customer right now. I think that's the way you need to think because you're focusing on the, it should be always a customer first approach. Vishakha Motwani: I'm very curious to hear from you. Like you talked so much about like you not only do you have to look at that one feature, but you're thinking in systems about where is it getting deployed? Do you have CI CD pipelines in place? Is it fast enough? So all these things I bet that there is you're thinking in terms of this holistic approach. But in your day-to-day, you already have some some of these things, Like you're building on top of it. But how do you go back and look back and try to improve? Raj: That's a great question. But if you see, it has not only impacted whatever the role I'm doing, right? It has impacted development. has impacted data analytics. And I think from what I see is like, every job is evolving. Every job is not going to get cut. To be honest, from what I see, the jobs are not going to get cut. Even in the future, the, how the tools are, how the jobs are evolving. And I, I should also say that we should also evolve with whatever is happening. We should accept it and we should evolve with that. And if you with respect to what QA and how A has impacted, right? Right now, previously I had a lot of restrictions that couple of things which I didn't know to do, for example, taking it up, bringing up a Kubernetes pod or Docker and then writing, writing playwright. or using Playwright to do your UI or using fast APIs to test all your API related testing or build up something, some tool that will give you an impact to the team or it will help in this one, right? It will take days or weeks or months to come up with a design and... and implement it right and then it has to go through and it has to go through a lot of iteration. Nowadays, it's like it's like two days, three days in a week. You come up with a design, but I think you should come up with a solid design and you should have more context on what you're trying to build and how you give your prompts and how you work on it. Things like that. It's very interesting because I, it kind of moved that thin line where I wasn't able to build all these things. Now we are able to build all these things. And apart from the tools that kind of help you in your SDLC cycle, like test case, generation, test case, automation, and then deployment and things like that. I think I've started exploring more on failure analysis predictive tools. Like how do you analyze failures before you move your feature or whatever the code that is coming into the customers? started exploring more on how you build some, failure predictive analysis. So that it's very useful for us when you come up with a release, right? Everybody, you really don't know whether this release is going to impact your customer or not, right? You'll be very worried about how you're doing your, how you're fixing the bugs, how many regression sweets are there, how is it running and things like that. But what does your code actually doing to your customer once it goes to deploy? Is this code affecting anything that the customer because most of the customers won't need your new features, right? They just want whatever it's working and And there was another thing where we kind of there was another cool thing that we that a company that we partnered with the mythos or Anthropic with anthropic right so that we could get in all the code vulnerabilities where the code leaks are happening. That was like a game changer. I think even most of the Palo Alto networks, even Nikesh was like raving about how mythos is right. So that was a game changer model for most of the security companies that we were able to see the we were able to understand the code vulnerabilities that we had internally and what the open source packages. and everything we built a harness. We built a harness with multi agent architecture where we could like run multi agent using my those model to predict all these and and we were able to do this in like weeks like in a in two to three weeks we were able to analyze we were able to do it and then roll it out to the customers. Right. So I think it has transitioned the implementation part has like that part has really vanished. But I think how you how you are thinking, how contextually you are thinking and going forward with how you are using AI is, I think, is the real question. How you want to use the AI and how we want to develop. If you see it as a threat, I think that that itself, are like stopping your progress. So I think that's what, that's how I see it. Vishakha Motwani: I love that, Raj. Thank you for give for giving us like real life examples because that brings everything into perspective. It's one thing to say that we're looking for code vulnerabilities and security issues, but to actually see it live and then for you to be able to implement systems around that is like thank you for sharing that. One of the things you had mentioned that you're building harnesses and I I feel like I might be going off track, but could you give us a little bit like a one to two minute feel on like what does it mean to have a testing harness? I see that term used a lot these days. and maybe it existed before also, but have having you here and you speaking about it, I would love to hear what you have to share on the harness aspect of it. Raj: I mean like, yeah, like you mentioned like it's a more common word right now in the industry, like having a testing harness that completely does your SDLC cycle. does, you give your FSN PRD to it and then it kind of generates all your test case. So how I see this testing harness as of is like you give your PRD and function spec and then it kind of goes and gets you your test cases. and it kind of generates a test case automation, it kind of runs it and it kind of deploys it to your testing staging environment and you kind of test it, right? So that's how I see it. But if it is effective 100%, I cannot give that word because it's more on context, right? How you write your skills around skills and how you write it and how effective it is. Someone has to like for now, I feel like It really involves some human intervention. It's not like the Astra model that is that recently came in, right? That you just give you a laptop. It goes and does everything for you. Just come back and you just go for a coffee and come back. It's not we're not there yet, but we'll definitely be there with all how the AI is evolving. Right. But mainly the testing harness is like to be it's like to get you out from the traditional way of your testing cycles and help the engineer to do something to solve more engineering problems than your release issues. So you have a testing owner that takes care of your release workflow. And then you go and worry about all the engineering problems that you can solve within the team. Like I mentioned, like a predictive analyzer, a failure predictive analyzer, or you can work on few other things that will create an impact for other cross-functional teams. Yeah, so that's how I see the testing harness right now is Vishakha Motwani: Okay. Raj: it's just like trying to help you like do the whole testing workflow with multi agent architecture. But if it Vishakha Motwani: Okay. yeah. Raj: is it like doing everything like you have multi agents that you have one orchestrator and you have multi agents that are spun through the harness that goes and does like you have a Jira NCP you have Vishakha Motwani: Mm. Raj: a test rail MCP and things like that. It gets the data. It goes and does all your, it goes, does all your test case generation, test case automation and things like that. But if you say if it is a hundred percent effective, I wouldn't say because of more of the context and how it is going, but we are, we are trying to get, get that. Vishakha Motwani: It's a process, right? Like not every new Raj: It's a process, yeah. Vishakha Motwani: thing you bring in. It takes time for that specific piece to get accustomed to the environment that you're building and also to train it in a way that you want it to behave. Like it gives you valid results and it gives you something to l to put forward, like to make use of it. I'm going to shift gears a little bit on the human side of things where I feel like there is this idea that QA gets treated as a lesser track in engineering. And what would you tell someone who's early in their career who's worried about this instinctive like QA being a lesser track, I guess? Raj: I mean, this topic is a very good topic actually, because it's been there. It's not only been there. It's not something new. It's been there for a very long time. And unfortunately, Vishakha Motwani: Yes, yeah. Raj: I see a lot of QA engineers who also like kind of think that, okay, it's kind of a lesser track. think I have seen a lot of my friends who have also thought like that and they are moved to PM development, SREs, they have transitioned to that. Basically, I can talk for myself first because I also had this thought to be honest, am I like, this build, is this going to be there in the future? It is still here, even in the AI era, if you think even now with the AI transition, the job is still there. Most of the jobs are still there, which we thought is going to be cut. From what I see is like, I personally feel like you should always analyze what you're good at. You should know what you're good at. should not think that what other people what other people are. They might be good at that. Okay. But you should first have a honest self evaluation of whether whether you'll be good at it. For example, I always wanted to move to development because but I always had a thought whether I would I be a good developer because right now I'm a good QA. I'm good at QA. I'm good at what I'm doing. But if I go into development, it's a lot more like system design and things like that. But right now, I think the line between development and QA is actually a very thin line. Okay. So it's not like, I know I see a lot of companies who just have one team that just develops and does the testing. So I don't think so the barrier is still there, but you are right. The thought of taking it as a profession has always been like, okay, it is not the development or it's not like a PM and things like that. But a person who wants to come and who wants to pursue this as a career, who's a very early is and is at a very early stage, right? Whatever I spoke right now, always don't think about just the feature. Don't like restrict yourself to just do writing test cases or taking a test plan and writing the automation for it and then and then leave it from there. Don't think in that if you think in that perspective, I think it's a very tough road for everyone, I guess. But you have to think in the perspective of you need to work on system design. You need to get yourself involved in design discussions like nowadays, like I see a healthy way of icing. Whenever there is a discussion, I think they involve all the PM development and QA folks to go through the when they have a PRD from the customer, they just want to understand because from the development side, you will be looking at how how to implement this feature rate with whatever you have. But from the QA side, you will get a lot more perspective. Like what would be the impact if this feature rolls out? Will this feature actually work? Because you have a lot of cross-functional Now with every company moving towards platformization, right? They just want one integrated security or any platform that needs to work across which handles all the workflows, all the context and things like that for all the customers. So when you think in that perspective, it becomes even more complex. And from what as the engineer, should always, you should learn, read and learn a lot of tools like You should learn about what is Kubernetes, what is Docker, what is Playwright and you should know how to write a CI CD pipelines and automation is the basic but system design and learning about distributed systems and microservices and learning about how and learning more about how your product is going to be like how your product is absorbed by your customer. That thing should always be there. I think if you, if you broaden your scope and not restrict yourself, I think you'll have a, I think you'll be able to evolve over the industry is going. It should be open-minded. You shouldn't be more, it's not restricted. Vishakha Motwani: I Yeah. Raj: That's what I would say. Vishakha Motwani: I love that Russ. Thank you so much for being vulnerable and like sharing that this is like even when I wrote this question, I was still thinking that you know, it's going to be a debatable topic only because there are people that I've seen, they've had opinions about it and in a lesser way, right? Like and I I like that you've given this shift in perspective that if you think about test cases. And just your test plan, it is going to feel restrictive, right? It's going to feel like, okay, what am I doing? But the way that you have described that you're thinking in terms of the bigger system or even predictive failure analysis and things like that, you can grow in a role that you're in as long as you keep yourself open and keep yourself aware of the systems around you. And one of the things that you said, which I wholeheartedly agree that Eventually it's about the customer, how they are consuming it, do they need it? Are we serving the customer and the business eventually, right? So thank you for sharing that. And we can move to the other, the other aspect of your actual day-to-day work, which is like as a principal engineer in cloud security right now, what do you worry about day-to-day? Real threats versus theoretical ones? Raj: So, me as a whatever the work I do, right? I don't think about the everyday threats that are happening because that's more of a security analyst kind of a role. But whatever I do is like, I worry more about the infra. What is being deployed to the customers? How the infra is, is the infra ready for the security threats that are going to happen? Right. So I, I, I worry more on that. So I, I, I worry more on the infra side of like how, whether this, like I explained before, right? Whether this rollout is going to impact that customer or all the security vulnerabilities that I spoke about and things like that. So it's more on the infra level, infra level to make sure that the customer is like always in a, it's like in a safe space that any rollouts or any production issues they have been. taken care of. and we also worry about but whatever we work we also make sure that all these threats are threats are also being discarded. Right. That is also part of the world. But not every day I will be looking like OK this attacker is going to come and is going to do this or that. No it's more on the infrared side. That's how that's my that's my primary work. Vishakha Motwani: Yeah. Okay. And would you add anything to this aspect of infra where like how has that improved your way of thinking over the past few years that you've been in this space? Raj: I mean like, Infra wise I think previously I was more on the networking side because I did my telecommunication in networking masters. So I got, I moved to Cisco. At Cisco I was more on the layer. If you see that, I think you might know the TCP IP stack, right? So you are more on the layer two, layer three side. At that side, it's not like the Infra doesn't get that complex because you are worrying only about the bottom layer in your TCP stack. But now when I moved to Palo with the cloud security, right, you just moved up the layer, you moved up the application, the security and things like that, right. And it actually broadens the scope. It is very complicated, to be honest. All the SaaS product deployments, even though the customers are using it or things like that, and how you deploy all these releases to the customers, I think the infra itself has evolved and it's very complicated with the cloud when you deploy something on the cloud and all comes into place with the cost also you should make sure that cost is minimized. I think the deployment wise the complexity has increased and we are trying to do a lot in a single integrated system. So that's what I've seen which has evolved. And the complexity has increased, but we should make sure that customer doesn't realize that complexity, right? For him, it has to be like he brings up from our aspect, it's like a customer comes and brings up a firewall and he directs his traffic. And he should just make sure, Vishakha Motwani: Yeah. Raj: he should just be calm, like, okay, I'm not worried about any threats or something. But for him to do that in the background, there are a lot of complex things that are happening. And that complexity is the one that I see which has evolved over time. Vishakha Motwani: Yeah. Thank you for sharing that. I feel like that's a very I think that's where automation feels like it's such a different perspective that you come from the other side and you you still let the customer do the thing that they were doing seamlessly. And that that brings me to one more question. You talked a lot about like comp complexity increment. in your role, like how do you measure success? Like how do you know when the path that you did or the infra that you built has been successful? What kind of matrix, if there are any, are are you measuring any matrix or how do you decide that we did a great job, like as a team, as a person, as a QA engineer or a principal engineer? Raj: So if you see in release, right, there are a lot of things that are happening. And if you were just asking about an in talking about my individual metrics that I see, okay, I've done a good job or something like that, right? I think I would measure it with the number of the less manual intervention that I have done in this particular release. See, people, I think that is another debate also. Within QA itself, you'll see that'll be a debate about doing automation and doing manual. Okay. I think it goes hand in hand. You need to be good at both. Manual, it will give you a very good understanding of the system that you're trying to automate. I usually first do my, I first If it's something new, just go and do it first on hands on. go and do it and make sure that I understand the workflow properly. And then only I go and automate it. So I spend a lot of time. If it is something new, I do it. I do that manual thing to make my, for my understanding. I don't, I don't disregard that. Okay. I won't do, I won't be doing any manual thing or something like that. Right. So the less manual intervention, for example, if, it's I'll come back to what I really want to talk about. you need to, I, for me, the metrics are the less manual intervention after the initial engagement of the feature, right? After that, how less manually am I doing doing this? Have I automated every other aspects? Am I able to automate every other? Have I covered all the corner cases? How many issues are these? It's not like you go and you go and log in and say, okay, the login is not working. That's not a, that's a That's like a P4 or P5 issue. Okay. How many P1 issues have you found it critically? these, would these have impacted the customer when you deploy it to the customer? Have you caught it before your deployment? How many issues that you have caught before you kind of moved to deployment that would have actually made a catastrophic thing once you deploy? The feedback once you get after the deployment happens from the customer, we do a soak period, right? And see how the customers are absorbing because sometimes when you, it's not like every time you go and deploy a very clean run, right? The minute you deploy in production, you get a pager call in the, you deploy in an hour or two also, you'll get a pager call. It's not like every time you can't say, I'm deploying it like a hundred percent like RFP. Sometimes you might miss. But how many issues that you, how many less issues that are seen in the customer is what your, should be your metrics. I think that's what it always goes back to. You always need to think from the deployment and once you deploy, think till your deployment is the, till your deployment to production is in your hands. The whatever the metric they would, whatever you can measure your metrics. Okay. You can have any, any number of metrics saying, okay. Vishakha Motwani: Yeah. Raj: you have done a good job, have automated all this and you have found these many issues. But once you deploy to the customers, no, it's only when you know that you're real metric. So from my understanding is like that how many how less manual intervention you have done once you are on your staging environment, Vishakha Motwani: Yes. Yeah. Raj: before you move to production, it should all be, by the time it should not, that it should be less manual intervention and how many P1 issues that are very critical that you have found. And this, your CI CD pipeline is all this, is it catching the issue when we are running, when you're running and all these integrations, how many issues that it has caught and Vishakha Motwani: Yes. Yeah. Raj: the reiteration because we do it in our QA environment. Now we have a staging environment then There are different stages right now from what I, what we do is like you have a QA environment, you have a staging environment, you have a pre-prod environment before you go to prod. In this, after all these three iterations and you still need to production issue, then I think whatever the metrics that you thought was not the real metrics. So that's Vishakha Motwani: Yes. Raj: how I see it. Yeah. Vishakha Motwani: that's perfectly put. Like you get three iterations to go through your product workload. Yeah. Raj: Yeah, you get three lines. Yeah, you get three lines, right? You actually get three lines. Vishakha Motwani: But that also gives you the perspective, right? Like, am I measuring the right thing? Am I trying to build in the metrics that are necessary from customers' aspect and also your organization's perspective, right? Like, are you bringing in Raj: Yeah. But yeah, if on top of that, right. All these three iteration, if you do it more manual or if you have more human intervention, it becomes more repetitive, right? For you, it's all you'll be like, okay, after QA, you go to the staging. Okay, QA it work. Okay, staging. Okay, staging also should work. Vishakha Motwani: Yeah. Yeah. Raj: Let's go to prep. You should build your infra such that it is able to do it consistently across all these Vishakha Motwani: Do existed. Yeah. Raj: things. So that is very important from. Vishakha Motwani: That makes sense. Yeah. And Raj: So this is where all these QA aspects comes into play, right? Because you make sure that. Vishakha Motwani: Yeah, absolutely. Like I I wanted to I I like that you said that, you know, it's so repetitive that sometimes you get too comfortable and too trustful, like, yeah, it worked in this environment, so you go to the next and it still works and you kind of tend to skip a few things and it's not it's not with bad intentions, I guess. It's just human tendency to kind of move through these phases faster. which is why you would have a harness or you would have your automation and infra in a way that does this for you. It doesn't matter how many times it has to repeat, but then also make it faster so that it moves faster through that process. the one thing Raj: Yeah. Even with AI right, sometimes even the human intervention becomes repetitive. Okay. You'll be like, okay, AI should be right. AI must be right. And you'll be like, okay, go, go, go. Okay, go, So that is also that. So I think you should have a balance. You should understand what you're doing. What is the AI doing? Vishakha Motwani: Yeah. Raj: And your writing and infrastructure is the AI doing the right thing. Vishakha Motwani: Yeah. Raj: and things like that. Yeah, even it's learning phase. If you ask me, have I implemented something which is like 100 % production ready or no, because even the model is learning, my skills are learning, even I am learning. So it's, Vishakha Motwani: Yeah. Raj: but we should learn, but right now with the space, right now I see how the industry is moving is like shift first, fix later. So in that. in that mode if we like go means even we have to be a little bit faster we have to learn fast it should be more adaptive so we need to from QA I think what I see is like we need to build that infra which is like fast and production ready all these in there that's why it more talk more about how we build the QA infra and it's not only about test cases and things like that so those are like all gone because the role Vishakha Motwani: Yeah. Raj: The has evolved from manual QA to automation to now it's like an AI QA. So that's how I see it. That's how the role has evolved. Vishakha Motwani: I love that. Thank you so much for sharing because this has been interesting on the difficulties and challenges that you face and to hear it from a person like you. Whereas I'm on this side of development process where I'm I might be thinking, yeah, how can I help the customer? But then eventually your job is also pretty much like keep it seamless, keep it so Easy for the users to come back, do the thing, and have that security layer always be present it with the increasing complexities of whatever it's being exposed exposed. But one last thing that I would love to ask you is Raj, what if there was one thing that you would expect from development engineers, the engineers that you work with who are building these features, what would be that one thing that you would like to have from them or like what would make your job easier if somebody on the engineering development process side did that for in collaboration with you. Raj: say like involve us more, us from the design phase so that it will be more easy because we should, we should see, we shouldn't see it as two different job or job roles, right? We are working towards the same goal. So I think involving QA from the start of design discussion and You don't need to like, like in one of those during your code process, but during design discussion, how you are going to design because right now how I see is like we already get a prop, we already get by involving QA after development is done. It's like you're already testing a failed product. That's what I see it. But if you more, if you involve QA even more and early engagement, we can rate the infra around your automation, around your, the code that you're developing. And the way you write it and baby tested can go in parallel and it can actually seamlessly go. don't need to come wait till you develop. then, then I, I consume it. And then I go and test it and come back to you again, saying that these are, these are all not working. And then it's like going back and forth and you are actually delaying the release process. I would say engage. I think have the design efforts, have the PM dev and QA in the same. in the same discussion, go through the process together. And I think that would be the best thing that you can give a good experience to the customer. Vishakha Motwani: I I love that. Thank you so much because that's something it's such an easy thing to do. Like, all you're asking is being involved, and that's it. Obviously, like it doesn't impact or it doesn't take a lot for me to have one more person in in that in that meeting or in that discussion, but it gives you so much more context around what we are building and what we are trying to serve to the customer so you can build. according to that, right? Like and like you said, it can be a process that we both follow together. You don't have to wait until the release or like rush through that process, I guess. So thank you so much. So Raj, we are at the part of the episode where I ask the same three questions to all my guests and the first one would be if there was one takeaway that people would get from this conversation, what would you have that be? Raj: I think Broaden your, whatever you're doing, whether you're doing a developer or SRE or QA or whatever your job role is, broaden it. Think in the customer, customer perspective, learn a lot of tools, keep evolving with how the industry is going, Think it more from an end to end perspective. Think it more, broaden your scope of your thoughts and learn a lot of things. Keep learning and learn all the latest tools or learn all the latest technologies. and keep yourself updated. Don't just restrict to your, I know life would be hard. Life is hard and you might be caught up with a lot of things, but don't spend an hour or so to, your, for your own enrichment. That's what I would say. Like people should take it from, from this podcast. Vishakha Motwani: Yeah, I love that. So at least you have this edge of comparing it with other tools and you can make a trade-off decision wisely rather than you have just one option and you look at it and you like go, yeah, this is the one thing, Raj: don't self doubt yourself because I have had the self doubt a lot when I was in my initial QA years but right now I don't have so always don't self doubt yourself I think you are always doing good that's what I always tell myself. Vishakha Motwani: Yeah. my god. So anybody listening, anybody self doubting, please contact Raj and he will help you through it. the second Raj: You Vishakha Motwani: question that I had for you was, is there a podcast, show, a book that you're reading that you've been loving lately? Raj: am more podcast person. I listen to a Vishakha Motwani: Okay. Raj: lot of podcasts but I don't have anything. You're talking about tech or general... Vishakha Motwani: Any like whatever you've been loving, hearing or watching Raj: I've been hearing I do a variety of podcasts. listen to a lot of audio books and lot of podcasts, be it tech or be it spirituality or be it and I do a lot of this maintaining your mental strength and things like that. I do a lot of podcasts. But the easiest way I would say like, you just insta reels and all these insta influencers who are in the who are doing all these AI content, right? Find the right content, guys, and just subscribe with them because you'll get that information way before anyone gets it. I think that's the quickest way. think that's what I felt like any AI updates I think if you follow all these insta influencers right you'll get all these information because I kind of don't see just as a social media platform but I get a lot of information from insta as well so find the right type of guys who do a lot of that a lot of good influencers who do right AI content so I'm on top of AI content because mainly because of them I would say Vishakha Motwani: nice. maybe later on you can send me a message of one of the people that you follow and I can add it in the description here for people who want to Raj: Go ahead. Yeah, yeah. Vishakha Motwani: like I understand that you if you don't remember at the top of your mind, but if you have some recommendation, I would love to put that at the bottom because I struggle with this so much that there are so many new things that that keep coming and you're like, how do I filter the information? To the one that I need, there are so many things out there, and newsletters and these small snippets are the one thing that you can look at it and go, like, okay, this is something that I need, and I can explore more. You can go and research more on those topics once you know that they exist. So I Raj: good. Vishakha Motwani: And the last question, Raj, what do you do for decompressing after work? What's your favourite way to just relax, I guess. Raj: okay. For me, I sure that I spend at least one hour for myself every day. That one hour is the one that I don't involve anyone now. My wife, my kids and my dogs. I don't do all that. So one hour is just for me. So I work out a lot. I do workout, do cardio and strength training. I think that... I morning I read some... I read a little bit of Bhagavad Gita or chant something. So that's a 10 minute thing. And after I close my laptop, it's all about my kids and the family. So I try to do all this early morning. I spend some time for myself early in the morning before people wake up. So that I'd because I don't get time after the day starts for everyone. So early morning I do all I do a workout. I read some, listen to chant or Bhagavad Gita and I do some workout. So I kind of restrict everything to an hour or an hour and 30 minutes for myself. I think that really helped me over the years. Once I started doing it, once I think I advise everyone to take that one hour or one hour, at least one hour for yourself in that day. I think that's the best decompress that you can do. Vishakha Motwani: I love that. I I wholeheartedly agree with that. Take time for yourself because that gives you some space to think about where you want to be, where you have been, and Raj: Yeah. Vishakha Motwani: like how you can progress further, be your career, family, personal life, however you want to call it. So thank you so much, Raj, for the conversation today. I hope you enjoyed this was whatever I had hoped it would be, and it was a very fun conversation for me. and I'll hope to see you soon. Thank you, Raj. Bye. Raj: Thank you. Thanks a lot. Thank you for having me also. Thank you. Have a good day.