How to land a software job in the age of LLMs
Aug 28, 2026 · 1 hr 2 min · 12 segments
Share Episode In this episode, we sit down with Nikhil Mungel, Head of AI R&D at…
- Show signals
- SuitabilitySafeBiasNot politicalAudience≈333 followers
Aug 28, 2026 · 1 hr 2 min · 12 segments
Share Episode In this episode, we sit down with Nikhil Mungel, Head of AI R&D at…
Yeah, for sure.
I mean, I think we took an approach that migrated to that sort of a long time ago from the very beginning.
I think the roots of where I came from, which was very not software driven, I worked in technical support for healthcare organizations and healthcare.
hands on the ground, but having to jump in and talk with actual customers and what they were facing forced me into a career path where I was always thinking about where was the value in what I was providing in the previous 10 years.
And when I shifted into leadership roles, I always was thinking, well, what is the value of software engineering in whatever we're doing in this regard? So LLMS didn't particularly change that for me, but it was definitely a hard sell for a lot of people because I said, you know what? Is software engineering a competitive advantage for our company? And I think a lot of companies that aren't very technical, jump up and say, no, of course not.
But ones with lots of engineering departments say, no, software engineering is a critical capacity that we have.
It's the thing that makes us stand out.
But if you actually look at the business model and the types of people that they hired, you can usually see, no, that actually isn't the case.
And now I feel like since technology often wasn't a company's competitive advantage, It's very easy, as you pointed out, if software development is commoditized or if it's just a utility, then you don't need to hire the best engineers or use the best LLM models or harnesses to get software developed.
And then the question is, what's left? And I think you're absolutely right.
What's left is making real time business decisions, but closer to the technology that you're creating.
100%, right? I mean, like, it's just expanding upon, you know, that core art of writing code or, you know, generating systems or, you know, maintaining systems or scaling systems and adding something else to it, right? So, like, the most successful developers I have seen thrive in these last couple of years have been developers that I've actually...
moved laterally, you know, when it comes to expanding their expanding their surface area, you're like maybe maybe gotten a little more product savvy, maybe gotten a little more business savvy where now they are, you know, connecting business outcomes to what they have been doing when because, again, writing code has gotten commoditized.
And, you know, there are there are a few dozen companies now that will send you a an SRE in a box or a DevOps engineer in a box, right, which believes to reduce mean time for resolution or, you know, just make sure your system is running all the time.
Because again, DevOps is just a different flavor of engineering and all of that is being short-circuited.
We had this, without going into too much detail, you know, we had this flow in the product where we were deciding whether to implement it in one particular direction or something else.
And this person tells me that, well, that's really a product call or just like a business call, you know, that's like, I'm just an engineer.
It's like, no, you know what? That answer may have been fine back in 2018 or 2015, but that's not going to sustain in 2026.
When I ask you a question, I expect a holistic answer, you know, something that shows me you have done your research, you have thought about this problem in its whole sense and not just the coding element of it, right? So what a great answer would have looked like in that particular scenario is like, well, if we do approach A, you know, we're going to get this, we're going to lose that.
Yeah, for sure.
I mean, I think we took an approach that migrated to that sort of a long time ago from the very beginning.
I think the roots of where I came from, which was very not software driven, I worked in technical support for healthcare organizations and healthcare.
hands on the ground, but having to jump in and talk with actual customers and what they were facing forced me into a career path where I was always thinking about where was the value in what I was providing in the previous 10 years.
And when I shifted into leadership roles, I always was thinking, well, what is the value of software engineering in whatever we're doing in this regard? So LLMS didn't particularly change that for me, but it was definitely a hard sell for a lot of people because I said, you know what? Is software engineering a competitive advantage for our company? And I think a lot of companies that aren't very technical, jump up and say, no, of course not.
But ones with lots of engineering departments say, no, software engineering is a critical capacity that we have.
It's the thing that makes us stand out.
But if you actually look at the business model and the types of people that they hired, you can usually see, no, that actually isn't the case.
And now I feel like since technology often wasn't a company's competitive advantage, It's very easy, as you pointed out, if software development is commoditized or if it's just a utility, then you don't need to hire the best engineers or use the best LLM models or harnesses to get software developed.
And then the question is, what's left? And I think you're absolutely right.
What's left is making real time business decisions, but closer to the technology that you're creating.
100%, right? I mean, like, it's just expanding upon, you know, that core art of writing code or, you know, generating systems or, you know, maintaining systems or scaling systems and adding something else to it, right? So, like, the most successful developers I have seen thrive in these last couple of years have been developers that I've actually...
moved laterally, you know, when it comes to expanding their expanding their surface area, you're like maybe maybe gotten a little more product savvy, maybe gotten a little more business savvy where now they are, you know, connecting business outcomes to what they have been doing when because, again, writing code has gotten commoditized.
And, you know, there are there are a few dozen companies now that will send you a an SRE in a box or a DevOps engineer in a box, right, which believes to reduce mean time for resolution or, you know, just make sure your system is running all the time.
Because again, DevOps is just a different flavor of engineering and all of that is being short-circuited.
We had this, without going into too much detail, you know, we had this flow in the product where we were deciding whether to implement it in one particular direction or something else.
And this person tells me that, well, that's really a product call or just like a business call, you know, that's like, I'm just an engineer.
It's like, no, you know what? That answer may have been fine back in 2018 or 2015, but that's not going to sustain in 2026.
When I ask you a question, I expect a holistic answer, you know, something that shows me you have done your research, you have thought about this problem in its whole sense and not just the coding element of it, right? So what a great answer would have looked like in that particular scenario is like, well, if we do approach A, you know, we're going to get this, we're going to lose that.
The rest of this transcript — segmented and speaker-labeled, so you land on the exact moment something was said
Search every transcript — by keyword, by phrase, or by meaning, across every show Radar indexes
Trends — what is surging across podcasts, measured against its own baseline
Alerts — when a name you follow appears in a newly indexed episode
No account is needed to search Radar.