87: Empowering the People Who Make Software with Yash Khandor of Mark43

Empowering the people making software is as important as the people using it. Yash Khandor is an engineering manager with a passion for mentorship. He joins the show to talk about the intangible traits of great developers, how not to hire developers, how to keep up with tech changes, and how to find software jobs that are less obvious.

In this episode, you will learn:

• Why Yash decided not to accept a job with Apple
• How not to hire developers and how to give feedback
• How to be intentional with your career growth
• How if you don’t update your knowledge, you get outdated
• Why startups don’t succeed
• Why you have to create your own method to your madness
• How to keep up with technology changes
• Why there’s nothing more satisfying than mentorship
• Why you should look for software jobs that are less obvious
• The intangible traits of great developers

This episode is brought to you by The Jed Mahonis Group, where we make sense of mobile app development with our non-technical approach to building custom mobile software solutions. Learn more at https://jmg.mn.

Recorded June 22, 2021 | Edited by Jordan Daoust | Produced by Jenny Karkowski

Show Links

Connect with Yash Khandor on LinkedIn | https://www.linkedin.com/in/yashkhandor/

MentorCruise | https://mentorcruise.com/mentor/yashkhandor/

Plato | https://www.platohq.com/mentors/yash-khandor-1635369491

Mark43 | https://www.mark43.com/

Episode 79: Balancing Managerial and Technical Responsibilities with Anand Safi of Mark43 | https://constantvariables.co/episodes/79

ClimateAction.tech | https://climateaction.tech/

ICN360.com | https://icn360.com

JMG Careers Page | https://jmg.mn/careers

Email careers@jmg.mn

Connect with Tim Bornholdt on LinkedIn | https://www.linkedin.com/in/timbornholdt/

Chat with The Jed Mahonis Group about your app dev questions | https://jmg.mn

Episode Transcript:

Tim Bornholdt 0:00
Welcome to Constant Variables, a podcast where we take a non technical look at building and growing digital products. I'm Tim Bornholdt. Let's get nerdy.

A quick note before jumping into this week's episode. We at The Jed Mahonis Group have a lot of fun projects coming in the door. And as a result, we're looking to expand our team by bringing on some iOS and Android developers. We at JMG place an emphasis on hiring for fit as opposed to skills. Skills are something that can be taught and fostered through mentorship and experience, which is something we talk about on today's episode. Fit on the other hand is a lot harder to define. But we've outlined some of the traits we're looking for on our careers page at jmg.mn/careers. So whether you have a year of experience or 20 years of experience, if you're interested in talking with us, please reach out at careers@jmg.mn. We'll put that link and a link to the careers page in our show notes as well.

Today, we are chatting with Yash Khandor, engineering manager at Mark43, a company name you might recognize from an earlier episode, which we'll link to in the show notes. Yash serves as a mentor to aspiring engineers by sharing the non tangible aspects of the journey. He particularly likes to inspire people who are looking to switch careers, but maybe feel they don't have the technical chops to land the job they want. So without further ado, here is my interview with Yash Khandor.

Yash. welcome to the show.

Yash Khandor 1:41
Hi, Tim, thank you for having me.

Tim Bornholdt 1:43
I'm really excited you reached out so that we could have this conversation. I'd love for you to take a chance to introduce yourself and tell us all about what you do and what you're up to.

Yash Khandor 1:52
Absolutely. So everybody knows now, my name is Yash Khandor. I currently work as an engineering manager for this company called Mark43. I'm currently based out of Toronto, Ontario. I'm also the founder and CEO for international cricket network ICN 360, which is a cricket game analysis and Broadcasting Corporation. I did my master's actually in the US from Carnegie Mellon University specializing in mathematical modeling and optimization. Apart from my day job, I also serve as a career advisor and an engineering and leadership mentor. With regards to hobbies, I mean, I love playing the sport of cricket. Like I said, I also love playing table tennis, which I used to play professionally back in India. I enjoy mentoring, pro bono consulting, keeping up with the latest and greatest in technology, and, most importantly, promoting diversity and inclusion. So that's broadly what I do. I can get into specifics of my role at Mark43 when we get to that conversation. But yeah, this is me in short.

Tim Bornholdt 2:57
I love it. I know you just said, you know, you've been all over with like corporate America, the startup life. Where do you think you've learned the most? Do you prefer startups over corporate culture? Or do you have a preference one way or the other?

Yash Khandor 3:11
I wouldn't say that. I think you learn at every stage. It's just the learnings are different. When you work in corporate America, you have different lessons that you learn. When you are in the startup culture, you learn different lessons. When you work for a startup versus own a startup, again, there are different lessons. I think the bottom line is you constantly learn. And as long as you accept that fact that you will always be learning and you will never be 100% you should be good in life.

Tim Bornholdt 3:38
Yeah, I can agree with that. I mean, I think no matter what you do, as long as you put yourself in a position to learn, then you can learn different things. Like the stuff you can learn at a startup where you get to be in the role of making tough decisions is, you know, one thing but then working in corporate America, sometimes you get to be in the role of getting to really focus on one niche and become an expert in one very specific field. So I think that's kind of a lesson I've learned, too, is just as long as you're open to accepting whatever position you're in and owning that and doing it to its best potential, then that's probably going to result in a successful engagement with wherever you are.

Yash Khandor 4:17
Absolutely.

Tim Bornholdt 4:19
Is it true that you were offered a job by Apple that you decided not to move forward with?

Yash Khandor 4:24
Yeah, that's a fun story. So basically, I graduated from Carnegie Mellon in December 2014. And then I was looking for a job. I did land one previously in IT, but then something happened with that company. I don't want to name them. But yeah, pretty big company, major company, but some change. So the hiring went on freeze. So then I moved to California to work for a startup there, but I was actually looking for something more concrete with all the visa issues surrounding international students. So while I was doing that, I had obviously interviewed with Apple and a bunch of other companies. But then Apple after the final round went cold on me for like three, four months. And obviously in the meantime, I found my other role of interest. And so I chose work, which is Raymond James Financial. So I chose working for Raymond James, moved to Tampa, Florida from California. I started working there. And then two weeks into my job at Raymond James, was just my second week, it wasn't even like complete two weeks, then I got a call from someone at Apple, probably like a third party contracting that Apple works with, because for international students, they sometimes hire you that way. So he said, Okay, we have an offer for you from Apple. So when would you like to join? And I was like, I don't know if you know what my status is right now in the market, or even if I'm in the market. So that was how it was, but at that point, I had made peace with the fact that I really want to work for Raymond James. Because when I got Raymond James, I got a couple of other offers. But I chose Raymond James for a reason, for the role, the profile, the team, and the responsibilities that I had got there. So I kind of planned like a few years down the line from that point too with Raymond James in mind. So plus, at that time, when I was looking for a job, I wanted somebody to trust me with this. And that person at Raymond James did that for me. So I thought it's imperative that I stay there. So that's why I chose not to go with Apple, nothing against Apple. I mean, it's a wonderful company to work with. I've a lot of friends actually work there. So yeah. But that's the story.

Tim Bornholdt 6:36
It's very clearly to me a lesson in how not to hire software developers. And it's one of those things, I think, what's the old saying, like the hens are coming home to roost, or however that goes. I think that there's been so much weird recruiting, like recruiters and the way that people get hired in this space has just gotten so ridiculous. And it's interesting when I work with, you know, junior developers, for example, trying to get their first jobs, the process that you go through to get hired as a technical person is just nuts. Are there any like lessons or things that you think you can pick out from that story with Apple? Or just generally things of when you're either looking to hire somebody as a software developer or if you are a developer, and you're going through this craziness? What are some lessons that companies can learn to make their process of bringing developers on board a little easier?

Yash Khandor 7:31
Absolutely. I think the most important lesson, that's something I implement in my day job as well, now that I'm an engineering manager, obviously, I mean, what to do with recruiting for my team. And also for like other teams in the company, one thing that's really important is while the candidate needs the job, I mean, at the end of the day, the company needs the candidate as much or even more for that matter, right? So why we don't want to as a company probably don't want to show that you're desperate. I mean, you're never desperate, but you still really need a good candidate. So it's okay to make your interview stuff, but it's not okay to make the process stuff. The process has to be friendly, I think, especially with software development. And just like the nature of software developers, it's important for them to feel in a space where, one, they have freedom of work. And secondly, I mean, you don't have to deal with an overhead of red tape or even like bureaucracy, for that matter. So as long as we can make the processes of our company for the interview process pretty straightforward, I think that that should be the most important thing out there.

Tim Bornholdt 8:41
Yeah. And I think too, it's hard in the United States, especially, there's so many, like fears of litigation of if you're going to hire somebody, and you tell them why you didn't hire them, you know, that that can open you up to some kind of class lawsuit, you know, for discrimination or something like that. And it's hard because I think those are, it just stinks being in this seat that we're in of actually hiring developers because you want to give people feedback, especially juniors. You want to be able to say, look, you just don't have the right skill set for this. I need you to work on a, b and c, but you sometimes feel like if you give that feedback, and your HR people tell you this, like if you give that feedback, you're opening yourself up to a potential liability. And so more often than not, people instead go completely the other direction and say, well, just not gonna give you any feedback and go silent. And we went through this whole interview process, and then we just don't talk to you for four months. And then in your case, someone reaches out and just says, All right, when you want to start? And it's like, oh, wait a minute, you just ghosted me for four months. Like, how does that help me? Is there any any advice or anything you could give for people like in that shoe of wanting to give feedback to developers, but do it in a way where they don't open themselves up to some kind of lawsuit?

Yash Khandor 10:04
Yeah, definitely. So one thing that we do is, we typically have like a standard template, right? If you don't want to go ahead with the candidate, there are reasons for it, obviously, or there are better candidates available or whatever. But we always have this open line of communication where if you want to get like good feedback, you can reach out to the person who interviewed you, right, for that matter, on LinkedIn or something right? Now, that is not exactly official on the company, for that matter. But we want to give like honest feedback right to you, so you can connect. And then potentially, I have had situations where there are people who did not, like, qualify in that interview. They reached out, they asked for feedback, I give them feedback. And eventually I turned out to be their mentor, and help them get a job somewhere, eventually. So I think that's where this entire interview process and the concept of interviewing should head towards. I know, I would have loved to hire that candidate for my company. But I mean, they did not make the cut, they did not make the cut, right? It's pretty black and white, there is nothing to hide. It's very transparent. These are the matrix. Okay, you did not qualify for the matrix. But now what next? I think the biggest question that a lot of devs out there have is, okay, I did not qualify here. But why? What next? What should I do? Like, people do courses all over the place. They read the books on Cracking the Coding, interview everything, but don't make the cut. So that's where I feel, taking it to a level where people can reach out to you outside of the formal process, say on LinkedIn or something like that. I think that that's beneficial for both.

Tim Bornholdt 11:46
Is there a way to give feedback, the way that you mentioned, the way that you just mentioned it, you said that there's a good way to get feedback from a professional standpoint, from like a technical coding standpoint of specific things you can work on? Whether it's, you know, algorithms or MVC, whatever, like just giving them feedback on that regard? But what about if it's like a culture thing? Like what if it's just there's something about the way like their demeanor, the way they they acted in a, you know, maybe they were the ones being late to giving you feedback or something. Is there a way to give feedback on soft skills as opposed to like the hard skills?

Yash Khandor 12:23
Yeah, I think that's the trickiest one of the lot. Yeah, that is actually the trickiest one. While you're interviewing, the trickiest interview, is when you actually give feedback for like, being an interviewer yourself, I think the most difficult one is the soft skills. Because, I mean, imagine going to somebody, you know what your attitude is not right for our company. I mean, that just doesn't sound right, really friendly. But yeah, I think that's the tricky one. I don't really have like an exact answer for this one. I think we treat this on a very ad hoc and a case by case basis, depending on, again, right, like, how far off is the candidate from your company culture. If it's really too far, I mean, it's very difficult to even you know, mention or negotiate those points. But sometimes when somebody is off by, say, a couple of values here and there, or maybe sometimes there is somebody else who is a much better cultural fit, not that this person is essentially not a good cultural fit. So in that scenario, it's much easier to convey the same. And again, like the line of communication, I think, even for this still remains the same.

Tim Bornholdt 13:34
Yeah, it's really hard to critique someone's soft skills, like going up to them and saying, you know, you're just you're surly, you're not a good communicator, like just things like that. It's sometimes hard, and especially, sometimes you just get a gut feeling about somebody that you're just like, there's just something I don't know what it is, but I can't, you know, so yeah, it's really hard to find that, though. And also, it's, you know, giving feedback on soft skills. That's some of the most personal, you're literally judging someone's personality, in a lot of cases. And it's like, how, you know, who are you to do that, but also at the same time, I think there's a way that you can give somebody feedback on personality things that might not mesh so that at least they've gotten the feedback. You don't have to be brutal about it, and list off, you know, 20 things. It's a little different with like technical skills. Those are things you can really learn quickly, where things like soft skills, it's hard to be like, okay, go and work on smiling or work on, like, being friendly or work on like, being a hard worker, like it's hard to to quantify that. So that's how I figured you to answer it is it's really ad hoc, and you have to take it on a case by case basis, but finding a way to not trounce somebody's feelings can be difficult.

Yash Khandor 14:51
Oh, definitely. And I mean, sometimes when you're interviewing, right, you have to take the hard path of not being able to give the most honest feedback. I mean, sometimes some people can come across with an attitude that doesn't really match with your company culture, not that that person is bad. I mean, obviously, the person has probably 15 years of experience in the industry or whatever, right? So they've been doing well in their life and in their careers. It's just that it doesn't match with your company. So it doesn't make sense to go up and tell them that, hey, you know what, you don't have the right attitude. I don't think that's the right way to go about it. It's just that okay, unfortunately, it's not working out for us in this space right now. Maybe we can cross paths in the future. But I mean, you really don't want to burn any bridges in the industry. That's like the main thing, whether you're interviewing somebody, or you're interviewing for somebody, I think as an interviewer and an interviewee, the most important thing is never to go, I will never burn any bridges. This is a very small world. That's the last thing you want to do.

Tim Bornholdt 15:53
It's so true. Like, I mean, I can pretty much name the vast majority of developers and people working in the Minneapolis area, at least in software. And it's like, you know, you and I are talking. And we're a couple of states apart, right? We're a country apart. But it's still like even just this like us talking, you meet all these people. And especially given things like LinkedIn and other social media, the second that you find out you have a mutual connection, and you know, I'm the interviewer, and you're the interviewee, I'm gonna go talk to those people and ask them, you know, how is this person? What are they like? And so if you have a reputation, that's not great. That's going to follow you. So yeah, absolutely do not burn bridges. As good as it might feel in the moment, you know, the internet doesn't forget, and the people whose bridge you just burned, it will also not forget, never.

So I mean, we talked about you jumping to the job that you took, instead of Apple. And I mean, you clearly made the right decision. Because within five years, you went from a junior developer to an engineering manager. What would you say has led to your rapid career growth in just the last five years? And also, if you want to touch on, where might you say you failed in those five years?

Yash Khandor 17:12
Sure. So to answer your first question, what's led to this fast growth? I think it was the ability. So when I chose this company over Apple, and I said that the responsibilities that I will get, so as a beginner developer, a lot of times you're not aware, right, like we join saying, Okay, I'm gonna work for a cool company and a cool product. But that's not about it, always. You want to probably learn the entire stack, you want to get your hands dirty, early in your career. I always say this, the ages 22 to 29, or even 24 to 29, this is your canvas, like the way you paint it, that's how it's gonna shape the landscape for you in the future. We try to be safe a lot of times in this years, when you're mature, and then you think, well, you're better than a lot of other people who are doing the crazy stuff. But I think it's good to keep the canvas clean, and just try to paint whatever you can in these five, six years.

And so when I took up this job, I think I was able to touch, while I focused on front end, so it's always good to have one niche, because that's what defines you. That's what will never put you out of the industry or out of a job, even in times of recession, because that's your expertise. But along with that expertise, everything in the periphery of that expertise, if you're aware of it and if you know how all of that works, it's very important because a lot of people talk about being full stack. I don't know how many real full stack developers actually exist. But I think what the industry expects from you as a full stack developer is an expertise in one part of the stack, and a very good general understanding of the other parts of the stack. And I kind of was lucky enough to get this advice from one of my heroes, my mentor, my manager, everything at Raymond James. I mean, I learned a lot from him, whether it's technology, whether it's career in technology, or whether it's even management. So I always attribute that to him. He's a very good friend of mine still.

So with regards to that, what made the difference in me growing in the career in the last five years, I was exposed not just to front end development, which is what I joined as a junior front end developer, but also to some parts of the back end, building API's, understanding the database, also moving towards becoming a subject matter expert, because I work for Raymond James Financial, it's a financial services company. So domain knowledge is equally important. When you delve deeper into domain knowledge, not all devs like to do it to be honest, a lot of devs by nature are like, okay, I all I care about is my code. I get things to work. That's my job. And it's personal. There's nothing wrong with that, you can do that. But for me, I never felt complete when I did that. So I always like to understand the business. If I'm building something or building a UI for something, okay, what's the user thinking? Why does the user really want this functionality? That helps me design better, that helps me code better. And that's how I got very close to the product side of things as well. I had very good friends on the product team on the business side. That's my core five years of work at Raymond James, where I did everything from project management to product management to development, became a tech leader at a point. And that's when I realized that, Oh, you know what, I really thrive in an environment where I want to club my technical acumen with the people management skills. And that's what brought me to this world of engineering management. So I worked for it. And then finally, luckily, I work as an engineering manager for that Mark43.

Tim Bornholdt 20:40
I really appreciate that feedback on getting deeper into domain knowledge. Because I know as I've been growing in my career that you can tell the developers that are, I mean, it's tough because you don't really have a lot of career growth. If you're just interested in coding, I mean, you can go from a junior coder to a senior coder, and then you're just working on tougher problems. But until you actually get into learning how the business works, and how you can take your skill sets and translate it to solve people's problems, then you're just going to be a coder. You're not going to be able to like progress further in your career. So I think that's something really important to highlight as a developer, you can't really be your best until you actually fully understand a problem. And you can't do that from behind a keyboard.

Yash Khandor 21:32
Yeah, I mean, I've seen people like excel in technical careers as well. I mean, they can end up being an architect. I think it comes down to what do you really want? Like, do you at any point want to be the face of the product or the face of the software that you're building? If that's the case, you need to understand the product. You need to get into people management. That's the only way to be the face of a product or a face of a project, or the face of the software. But if you just care about building really high quality software, because we need both kind of people, right, like if everyone wants to just be the face, you need somebody who's technically brilliant, and just only cares about code and infrastructure. So those are the archetypes. I think these are all different parts of a huge puzzle that need to fit together and make it like a fine tuned machine kind of thing. So I think you can do either, it depends on what you really want.

So I remember, you asked me where did I fail, right? I think I did not answer that part. So while I'm saying this, I realized, so there are a lot of places I failed to be honest. When I was doing front end, initially, I didn't realize how fast the front end world changes. So I learned the hard way that if you don't update yourself every three months, six months, you get outdated. So these are things you learn the hard way. I mean, people could have just told me that, but it's not always easy to you know, accept and understand what somebody is trying to tell you unless you experience it firsthand. It's bad on my part that I shouldn't have done that. I should have listened to people who have experience, but it's just natural. You're in that phase, you're young. So things happen. But so that was one place I feel failed.

The other place, I would say I failed was realizing the importance of product. Like I mentioned, I always like product, but I never realized how important it would be in shaping my career. So I could have potentially realized it a year earlier, not that it would have changed my career path. Like I said, I'm lucky to be where I am today, within the amount of time that I am. But it probably wouldn't have worked for everybody. Because I did lose on that one year, I would say I should have probably realized it a year ago. But like I said, you learn the hard way. And once you learn it the hard way, it never goes away.

Tim Bornholdt 23:47
Yeah, that lesson too of working in a team is one that I have really come to appreciate just in the last couple of years in my career, where I think especially young developers, everything does kind of ride on you, especially at the beginning. You know, like if you're in a startup landscape, you know that you are the one that's building this product. And it's kind of like the balls in your court, right, for the first few months, and maybe a couple of years. But then eventually, once you get the product developed and it's out the door, then it's really not, the balls out of your court, like you need a team of marketers, so people know about the product, a team of salespeople so that they can sell the product and a CFO looking at the numbers and like there's just all these people where if you go in with a big ego and say that you're kind of it, without you this wouldn't exist. It's like, Well, yeah, that's true. But without all these other people, you wouldn't still continue to be employed and have new features to add and continue to build on top of it. So I think that's an astute point that you kind of need to see the whole world and also not just be kind of wrapped up in your own thing. It's understanding that there's other parts to the business that all have to work in concert in order to actually be successful.

Yash Khandor 25:06
100%. Just to add to that, like we speak about a lot of startups in the Bay Area, like I was reading some statistics, when one startup opens up, two close in the Bay Area or something like that, some crazy statistics. The reason why all those startups fail, and we don't hear about them, they're probably technically sound. They're probably one of the finest, like few of the finest developers out there in the world. But why does this startup not succeed is because the other parts of the puzzle don't fit in. The marketing is not there, the sales is not there, the strategy is not there. You never know. It comes down to, Okay, our tech startup failed. But it's probably not the technology that failed them. Maybe it's the product that failed, maybe it's the marketing that failed. So it's very important to understand that.

Tim Bornholdt 25:50
100% and one of the things I wanted to highlight too, was when you had mentioned that the way that you kind of act from 24 to 29 can shape the rest of your career. And I just want to also agree 100% with that of, it's not to say like if you're in your 30s or 40s, that you can't get into this space, and you can't get going, you know. I think it's really just the lessons you learn and the way that you decide to go from kind of in your teens and in your early 20s, you're still kind of in that collegiate world of, you know, someone's kind of dictating a path for you to follow. And those first few years outside of those guardrails, you know, that the choices that you make of whether you're going to be focusing on something, whether you're going to be productive, whether you're going to, you know, build relationships, and kind of dig roots and all of that stuff, I guess, that maturing and that growing up process and figuring out your own path. And so I just want to say like, I completely agreed with that. And that I think it's also important to note, like, if you didn't get into development when you're 24, or in my case, when I was eight, it doesn't mean that you're going to have a crappy career, that you can't figure out development. It just means you're gonna have to put in a little bit of work to get caught up. But once you're here, you're here, you know.

Yash Khandor 27:13
Absolutely, I think it's a very good point to recite. I actually want to clarify when I said 22, or 24 to 29, is when you paint your canvas to shape the landscape of your future, I don't mean that you cannot if you're 32, or 35. So I'm all for this fact that irrespective of your background, irrespective of your age, irrespective of any external factors, it's up to you to get what you want. Just to give my example, I mean, I have a bachelor's in chemical engineering. I did my masters in mathematical modeling and optimization. I realized I want to build software for a financial company. So I entered the world of FinTech. From there, I realized I learned a lot in FinTech, I was like, Yeah, I want to work for a product company now. So got into this IoT, like an Internet of Things company, which builds business mobility solutions, so worked with them for a year. And then I was exposed to this world of public safety software, which is very cool at Mark43. And now I'm working as an engineering manager and not as a dev. Now, a lot of people might say that this is a very haphazard journey. But to be honest, there is a method to this madness. And I always tell people, you have to create the method to your own madness. People can think whatever they want to. A lot of successful people right at the end of the day, their story sounds like a perfect ending and a perfect storyline. But honestly, if you look at the intricate details, they have gone through everything, all sorts of things, before achieving the end goal. And when your end goal is good, your story always sounds good. So it's important to back yourself, irrespective of what phase of life you're in, whether it's age, what background you come from, I think all of those things, they don't matter. I'm not saying they don't, then that's why I mentioned 24 to 29. It's much easier to take risks during these times rather than 35 to 40. Probably when you have a family at stake, you know. So obviously, these factors do impact on your risk taking ability and stuff like that. But it doesn't stop you from achieving anything.

Tim Bornholdt 29:14
That's very well said. In your intro, you had mentioned that you love following technology and are constantly learning all the new stuff that's coming out there. How do you keep up with rapidly changing technology?

Yash Khandor 29:29
Yeah, that's like a million dollar question. So it's probably the first thing, to say that, okay, I'm 100% up to date, nobody's 100% up to date. If somebody tells you that they're probably lying for sure. Or they don't, they're not aware. But yeah, so I tend to try to achieve that. So I have subscriptions to certain tech journals that helps me know what's happening, latest and greatest. And again, like you potentially cannot know the entire spectrum of technology. You have to narrow down on, Okay, what are your areas of interest, you need to know, like the latest and greatest. Say, for example, I am on the front, like I have an expertise on the front end, and I enjoy front end. So I'm subscribed to these journals and conferences for say, React Angular, pure JavaScript stuff. And so I'm subscribed to this journalists and I hear more from them. Now, that doesn't mean I don't know what's happening in the world of AI. I kind of read newspapers here and there on these articles or Medium articles, here and there, that I'm subscribed to. So these helped me stay in the loop.

I think the greatest way I've been able to stay latest and greatest with technology is networking. It's one of the most underrated things for being up to date with technology. But I think your network, the amount of diversity in terms of knowledge that your network has, if on LinkedIn, for example, right, I have folks from across the spectrum on my network. So when I'm going through my LinkedIn feed, I see everything from AI to technology, to finance, to equity research, to world politics, to front end development. So that's how I kind of know what's happening everywhere. It's important to spend some time of your day to give yourself an ability to, you know, just take a step back from your regular work, know what's happening around in the world. That way, you're up to date with it. And then if you like something, if you're working on something that's latest and greatest, there is nothing better than being hands on. That's probably the only way to know something up to date ehen you when it comes to technology specifically.

Tim Bornholdt 31:37
Yeah, I find it difficult, and I guess it doesn't really matter what industry you're in, like pick web development, for example. There's like a new JavaScript framework that comes out every day. And it seems like you know, things like we've got TypeScript now. And that's, you know, not brand new, but still relatively new where I went, when I started programming, we just had like JavaScript version one. And it was just like being able to do that kind of dynamics that like the AJAX hadn't even existed yet. So it's going from that world of just writing vanilla JavaScript to now having to know how to work within, you know, frameworks, like React and using, you know, some type safe languages like TypeScript to kind of keep you in some guardrails and things like that. It's just, it is a never ending change, and a never ending journey. And that's one thing that's hard to underscore when you're a junior developer, is you think this like overwhelming tsunami of possibilities is like just, again, overwhelming, but it's never changing either. When you're in your career, you're never going to just kind of do the dust your hands off and say, I'm done. That's never the case with technology. And if that's not exciting to you, then I think you might struggle in this field. But I think a lot of people that really thrive in this field really thrive on the change in this and being able to kind of get deep in a framework for you know, 5,10 years, and then change to the next thing. And just it's usually natural progressions. It's very rarely, unless you kind of change jobs and kind of put yourself in a brand new position, it's very rarely where it's just abrupt stop where, well, I guess we're not doing like Objective C anymore, we're gonna just do Swift. It very rarely is that. It's more of like, oh, let's experiment with this Swift thing for a little bit. And then a couple of years go by, and then yeah, why don't we start this new project in Swift? And then you kind of keep going, and after a few years, it's, well look at this old Objective C code, maybe we need to update that and convert it to Swift. And it's usually like that, I find. Is that how you see it too? Or do you see a lot of times in your career where you have to just all of a sudden stop and learn a brand new thing?

Yash Khandor 33:52
It's usually a general progression, I would say. If there is a phase where you have to suddenly stop and learn something new, that's usually when you slacked, to be honest. I mean, no company is going to say, oh, you're an Angular one, point x, for example. And now Angular two is out. Oh, let's switch to Angular two, that never happens. I mean, if it's difficult for you to switch, it's 10 times or 20 times or maybe even 50 times more difficult for an organization or an enterprise software to switch frameworks. So obviously, that decision doesn't happen overnight. But if you feel that things are happening overnight, that's either like really bad planning on the organizational front, which is usually not the case. It's usually you who slacked, like they're not kept up to date. And if that happens, I mean, you got to learn, you got to learn, right? I mean, we can complain all we want, especially in the web development, or the front end space that, Oh, Angular. I used to do that when I was a dev. Angular comes up with a new version every six months. It's crazy. And but it is what it is, what do you do? You wanted the new features. Yeah, you got the new features.

So I mean, I think one more point that's important here is there's so much to learn. You did mention the right word, overwhelmed, right? As a dev or a junior dev, you probably get like overwhelmed with all the technology that's out there. It's very important to define for yourself what you really want. I mean, even within a space that's as niche as a web development space, or like a front end development space, those are React, there's an Angular, this backbone, there are so many frameworks, where you need to determine at one point, what framework you want to get into, and then consolidate working on that. I mean, react and angular are very different. To be honest, I work with both. I can say that they're very different. You can't say that I know both Angular and react unless you've studied both. It's not that, okay, I've learned Angular so I can do react, or I've learned react, I can do and you know, it's not that straightforward. But what's important is that the underlining JavaScript fundamentals, which is the core of front end development, is clear. Once that is clear, if your computer science fundamentals are clear, you can even easily pick up TypeScript. If that was clear, you can pick up a framework. So it's really important to define for yourself and for the technology that you're working on what's really important. Frameworks will change, but the core language, the core fundamentals won't, so you need to be really good at your fundamentals. The frameworks can change, and you can pick them up. So otherwise, it's just impossible. You'll always feel you are not up to date, and you don't know so many things. It's very easy to get bogged down in this industry, because of your 15 friends, 13 might be doing completely different things from what you're doing. That doesn't mean you don't know their stuff. Well, it means you don't know those certain things, 13 things, that doesn't mean that you have to know all those 13 things, because potentially those 13 people don't know what you know, so it's important to know what you know, very precisely, and very strongly, and then just know whereabouts of the other things in the periphery.

Tim Bornholdt 35:18
I feel like you called me out pretty hard on saying if you're not keeping up, it's your own fault. Cause it's so true. And that's how I feel about this world of react and these frameworks, because I did step away for a long time and like, got stuck in my ways, and it's something that I'm continuing to get better at is just picking it up and trying some projects. And it is like, once you understand how JavaScript works, then you can, it doesn't take much to go up a level and understand how TypeScript works, then it doesn't really take that much to understand someone's, because all these frameworks are opinionated by nature, right? Like, this is good, the designers say, you know, this is how you build a proper web app. And the way that you do that for Angular and view and react are completely different. That's why they exist as completely different things. So I think that's one thing I've learned is you kind of have to figure out what framework you can kind of warp your worldview to match and then just live in it and accept and take all the trade offs that you get. There's a lot of benefits to changing your world to match the way those frameworks think. But then you also have to kind of accept the trade offs and the cons of working with some of those potential frameworks. Because otherwise, if you're spending your time battling these frameworks, then you're not really doing yourself any service.

Unknown Speaker 36:57
100%. I mean that's the reasion why they're called frameworks, right? Like, by definition framework is a supporting structure to a building. It's not really the building, the building is the language, the framework is the supporting structure to it. So what's important is the fundamentals of the language, which is JavaScript or TypeScript.

Tim Bornholdt 38:41
Exactly. So I know you're a mentor, and you do a lot of mentoring for aspiring engineers. What inspired you to go help people figure out how to get into this space? Or how to help people switch careers within engineering?

Yash Khandor 38:54
That's a very interesting question. I mean, I read this somewhere and I think I made this my life mission statement, kind of, I don't remember who said it. But I remember somebody saying that I was born in this world with nothing, but I want to leave behind something positive in my lifetime, something like a legacy. And that kind of struck a chord with me. Why mentorship? I mean, there is nothing more satisfying than changing someone's world and like shaping their life or careers. I don't think anything ever comes closer than that, to success, to defining success or happiness. Plus, in addition to mentorship, the reasons are like, I like to gain new perspectives, fresh ideas that help me see things differently when I mentor people. It also helps me reinforce my own knowledge and helps me keep relevant with this. Like we spoke about the fast and the ever changing tech world. Also it helps me broaden my network and it shapes the leaders for tomorrow. It not only shows my leadership skills or helps me become a better leader. It also helps me shape the leaders of tomorrow, which goes a long way, honestly.

I do a lot of importance to emotional intelligence. That's something I've learned over a period of time. And mentorship is one of the best ways to practice emotional intelligence, I feel. And like I said, last but not the least, I mean, I would say the sense of fulfillment that you get, the sense of growth, it basically allows me to give it back to the community. These are basically I would say, probably the reasons like why I got into mentorship. How I was motivated for this was when I was going through my education, looking for a job, growth in the career, switching in the careers, I felt that a lot of places I learned a lot of things, I made a lot of mistakes. There were things I was not told by anybody, I learned the hard way. And I've always believed you're always allowed to make mistakes, everybody's allowed to make mistakes. As long as you don't make the same mistake multiple times, you're allowed to make mistakes, but you also don't have a lifespan that's long enough that you can always make all the mistakes. You potentially have to learn from others' mistakes. I think jack ma mentioned this in one of his talks that the greatest way to grow is to learn from others mistakes and that's what I try to facilitate other people with when I mentor, where they don't make the same mistakes I did. That kind of speeds up their growth, I feel so then they are allowed to make other mistakes, which I potentially wasn't even allowed because I made some of the mistakes, which they will probably not make, because I'm mentoring them.

Tim Bornholdt 41:36
I think that's one thing I've been thinking about a lot lately is just how the internet, we're still kind of dealing with like as a just civilization and as humans, we're still kind of trying to deal with just having the internet. Because I think you're right in that we learn best, we can learn better, if we take other people's mistakes and figure out how not to do something. That can help us figure out how the right way to do something is and we haven't been able to have like, we've had pockets like within countries, within states and cities and provinces, like as you shrink it down, you know, you get your localized group of people that you can figure out mistakes from. But now there's a whole world of people that have made mistakes that I wouldn't have even considered making, or even considered that there was a possibility to even make the choice that they made. Because you listen to it on a podcast or you hear it in a talk going to a conference or you go on like a TED talk and learn somebody's ideas. And I think that's something that's kind of bringing it back to to mentoring students. It's so cool that we're able to mentor other people in this space. And you know, you kind of get the you know, old man waving at a cloud or like the grandpa being like, you know, back in my day when I was programming, you kind of get you get on a soapbox, sometimes from time to time, but I think as much as somebody might roll their eyes at a story like that, those stories are the ones where you can really, you know, synthesize what you will out of it. Either be appreciative of now that we have frameworks and things like that that people have built or just learning these simple lessons of how to deal with people and interpersonal skills or whatever. It is really cool that we're able to as mentors pass that information on to others and do it at a potentially, you know, even with this podcast, like this is ephemeral, you know. This is gonna live for as long as I guess we keep paying the Libsyn bill for hosting the mp3. So there's potentially an unlimited number of people who can listen to this and learn from the mistakes that we've made as developers. And just it's a really cool prospect. And I'm glad you have that perspective on mentoring, because I think a lot of people really do benefit from us having these rambling talks that we have.

Unknown Speaker 43:57
Oh, 100%. I mean, I think you're right, with regards to a lot of times when we mention our experiences, or even like guide people, it's possible, it's very much possible that people don't fully relate to or resonate with what we're saying. I mean, when I was younger, I mean, not that I'm old. I don't want to say that. But when I was like in my, I wouldn't say teenager, but like, like, five, six years ago, when I would hear somebody say things like what are good for your career, and stuff like that. I was like, Yeah, you're saying this, because you've already achieved it. It's all good talk. But it doesn't work in the real world. That's what my attitude was. But then sometimes you learn it the hard way. And then once you have it, once you learned the hard way, you're like, Oh, it's important to listen, there's no harm in listening to somebody, right? You never know when it's going to be helpful. And now when I mentor people, I do get the feeling or vibe from some of them that, Oh, yeah, you're talking something that's too ideal, or you're talking something that I read in a book, but it's very good theoretically, not probably not practically, but sometimes it is. I know, like 80% of what we read in the books probably doesn't apply to the real world. But the 20% does, and that's very important. So, yeah, I wouldn't say mentorship is a thankless job. I wouldn't go to that extent. There are times where, while it doesn't go the way you want it to, but that's not what you're in that for, right? You're there to just dissipate your knowledge. And hopefully, it's going to help people and more often than not, it does.

Tim Bornholdt 45:33
Right. And it's just like, I don't know if you have children or not, but I have two young children. And that's I mean, mentoring software engineers and parenting, it can really, the corollary there is quite strong. You can tell people time and time again, like okay, just commit your code often. Like just, it's all those, you know, floss and brush your teeth. It's all these like things that you tell people like, okay, just make sure you do this, because you will regret it if you don't. You can yell at people till you're blue in the teeth, and suggest people do it, maybe not even yelling. But it's one of those things where at some point, your advice is going to click for them. And you're just going to be very proud that they figured it out on their own and maybe failed in their own way or whatever. But you at least were there to kind of steer them in the right direction and at least put those things into the back of their mind. So that later on, hopefully they apply the lessons learned that you've tried to bestow on them. And just I mean, that's just how the world goes, right?

Yash Khandor 46:35
That's a great way to put it. I mean, I don't have kids yet. But I think I can imagine what you really want to say with that thing. That's a very good analogy, to be honest.

Tim Bornholdt 46:46
So another topic here. So if you don't work in tech every day, and frankly, even if you do, it's hard to know all the tech companies you could work for and people often want to work for, you know, Google and Facebook and all the big tech companies, but how do you suggest people get familiar with all of the options that exist for working in this giant software industry of ours?

Yash Khandor 47:08
Again, two points to this question. One, you will never be aware of every company out there. And the second thing is to think out of the box, think beyond what's obvious to you. Because what's obvious to you is obvious to 99.9 percent of the other people. So try to find things that are outside of that. A lot of people who only go for the Googles and the Facebook's and the Amazon, there's nothing wrong about it. I'm not saying there's anything wrong about it. Those are great companies to work for, with great benefits. But having said that, that's not where you want to limit yourself. I mean, let's take Mark43, for example. It's not a company that small, it's not a company that's not doing cool stuff. In fact, it is a company that's actually making real world difference to our communities on a day to day basis. I mean, we build software for public safety for first responders. Like we really know that there was a fire that broke out. So like during the forest fires in California, we knew that our software is being used to dispatch units and save lives of like hundreds of people. That is immense satisfaction. But a lot of people like majority of the people probably don't even know what Mark43does. And I wouldn't blame them for that. But the fact that there are so many companies out there, it's important for you to like, check out, like use resources. I mean, there was internet out there, there is no reason for you to say ,Oh, I didn't, I could not find information about this. If somebody cannot find information in this world of internet, they probably don't know where and how to find it. Or know how to find it. So that's a problem with you if you cannot find information. So I would say be more curious, be inquisitive, try to be away from just what the obvious is. Because, like I said, What's obvious to you is obvious to the other 99.9 percentile. So if you want to be different, you want to do something out of the box, there are so many companies out there.

Also you need to define what your life goal is. I mean, do you want to build a software that's going to support social media? Social networks? Yeah, then that's cool. But do you want to build a software that actually makes difference to the communities in the real life? Yeah, do that. Do you want to build a software that's going to make manufacturing and supply chain easier? Target companies like that. Do you want to contribute to the food industry? So it also depends on what you want to really contribute your software skills to? Because everywhere you're just going to do potentially the same thing, which is coding. But at the end of the day, what is your software being used for? Does that matter to you? I hope it does, because it should to everybody out there. Your product is what defines your work. At the end of the day, your code is for the layman, your code is basically the product that's being shipped out. So so it's important to define that, and then do your due diligence, do the research, get more information.

Tim Bornholdt 50:05
It seems like there's a common trope in technology that you can kind of just put in 10 years at a Google or Facebook or something and make your millions, get your stock options and then bounce and go do something else. And I think it seems like there's such a disservice, like you said, there's so like, with all the smarts that people have out there, and with all of the horrible problems that plague other humans, and just our world, and there's an endless supply of problems to solve. And I think figuring out some of those problems that you're passionate about, and going and getting embedded in those communities, like, if you're really worried about climate change, for example, there are so many resources out there. I'm in this this slack group called climate action tech, and they have a jobs page that is just endless with all these startups that are doing things in the climate change and not just startups but bigger businesses as well are hiring for people that can solve problems with sustainability and with accountability, and all those different things. Like if you're interested in public safety, there's got to be a similar thing that would ultimately lead people to your organization that you can help build software that is going to solve actual problems. And so yeah, I think to be able to figure out what's all out there, you really have to take an internal look and figure out what's important to you. And that's not always easy to do. But if you can put in that effort to figure out the kind of things that you're passionate about, and that you want to spend, you know, part of your career like, let's not fool ourselves, like you can always change jobs and go find something else. So it's not like if you make a decision today that five years from now you can't change it and go find something else. You absolutely can. But the point is like just start somewhere and start based off of things that are going to drive you and get that intrinsic motivation instead of just going for the company that's going to offer you a giant check. And I guess unless that is what you want is just five Ferrari's then go ahead and work at a giant company and work your way up to be making millions of dollars in salary and go from there. But I don't know, I don't think most people operate that way, personally.

Yash Khandor 52:16
Exactly like you said, like it's very personal. But if somebody says they don't know about it, or there's not enough information about it, or they cannot do it. That's where I have a problem. I'm like, No, that's not true. You're telling yourself a lie, which is preventing you from doing it. Or maybe you're trying to cool your tracks and you really don't want to do it. So that's where the problem is. But if you're clear, okay, I want to work for a tech giant. That's what I want to do. Yeah, fair, there is a career path there, which is a very well defined and a clear path that everybody knows about. So that's perfectly fine. That's your method to madness. Right? So again, it's very personal. But there is no way to say that you cannot do it, or you don't have enough information or resources to do it in this world right now.

Tim Bornholdt 53:00
I couldn't agree more. Last question for you. Outside of technical capabilities, there's a lot of intangible traits that make for a successful developer. And we kind of talked about this a little bit before. But what are some traits that you see as most valuable? And how do you think developers can cultivate those traits?

Yash Khandor 53:21
Absolutely, I think you're absolutely right. Even when I'm hiring, right, these days, while I have really smart people, people with like, crazy, technical acumen, how to differentiate between them, it has to come from these intangible aspects, these skills. I think communication goes a long, long, long way, especially when you work in a team setting. I mean, you can be the best developer out there, best front end developer out there. But if you don't truly communicate well, and because of you, the back end is out of sync, the back end developer doesn't know what's happening. At the end of the day, you can build the best front end, but it's not going to integrate well with the API's. I'm giving you a very lame and a very, very basic example. But like something as basic as that there's going to be reverb that's required, and that cost the company. You won't be able to deliver something by the deadline within the timeline, just because there wasn't enough communication. I think it's very underrated. So communication, I think goes a long, long way. And it's very important.

The other one I've learned, I think I've learned this the hard way as well. It is patience. Patience, I think, is a virtue that only the greats possess, in software specifically, right. Especially when you are in the management side of things, it's very difficult to convince the stakeholders that software takes time. The amount of time that it takes is real. And then even more difficult to convince them is that if I try to rush, this is going to slow it down and make it buggy. I've always maintained this that, I read this somewhere but it is very, very beautifully written it said, Slow is smooth, and smooth is fast. So patience will help you move faster, and patience is everything. So that's something very important to learn, whether you're a software developer or whether you're, and more importantly, if you're a software manager. Sometimes trying to put like, if your two resources can do something in six days, put on three more to do it in two days, that's something to understand very clearly. It doesn't work that way.

Tim Bornholdt 55:24
I've always found the mythical man month where they say you can't take nine women and make a baby in a month. It's the exact same way with software, like things just take certain amounts of time. And, and even if you throw more people at the problem, that's not going to necessarily speed things up. In fact, when you throw more people at a problem, then you've got a communication hurdle that you need to work with and make sure that you've got this system moving in sync in lockstep together to be able to achieve certain timelines. So yeah, I couldn't agree more with the patience side of things and communication as well. That's like, I think we preach on that on this show so often, but definitely the patience I'd say. And that's a good good lesson if you're listening to this episode as potentially an engineering manager or a hiring manager, that just understanding that software, you can't just snap your fingers and have things done, like what we do is magic to a certain degree. But it's not. There's also some roots in physics and practicality that you can't just build everything on a dime.

Yash Khandor 56:27
100%.

Tim Bornholdt 56:29
Gosh, this was so much fun. I'm really glad that you reached out and asked to be on the show, because I had a tremendous time. How can people get in touch with you and learn more about the work that you're doing just all over the place?

Yash Khandor 56:42
No, absolutely. I think LinkedIn is the best way to get in touch with me. I don't mind sharing my personal email as well with you, which you can put in the description. But I think I will be the most responsive on LinkedIn. I'll share my LinkedIn profile as well. So yeah, I'd be more than happy to help. I'm also on MentorCruise, and Plato as a mentor. So if you require mentorship, you can just subscribe to me there. They all have like free trials, just in case somebody is curious about the pricing and stuff. So you can always have like, connect me with me there. So if you want to just say hi or like, you know, just connect with me on LinkedIn. But if you want to get like real hands on mentorship, I would say Mentor Cruise,Plato. I'll share all the links with you, Tim, so that the viewers, the audience, can actually get access to it. But yeah, so it's LinkedIn and email.

Tim Bornholdt 57:32
Fantastic. We'll make sure we throw those links in the show notes. And, Yash, thank you again for joining me today.

Yash Khandor 57:38
Thank you so much for having me. It was a pleasure talking with you. And it was great fun.

Tim Bornholdt 57:44
Thanks to Yash Khandor for joining me on the podcast today. You can learn more about Yash by connecting with him on LinkedIn or email and both of those will be linked to in our show notes.

Speaking of which, Show Notes for this episode can be found at constantvariables.co. You can get in touch with us by emailing Hello@constantvariables.co. I'm @TimBornholdt on Twitter. The show is @CV_podcast. Today's episode was produced by Jenny Karkowski and was edited by the great Jordan Daoust.

If you loved this episode and could spare just one minute of your time, we'd love it if you left us a review on the apple podcast app, just head to constantvariables.co/review and we'll get you to the right place. This episode was brought to you by The Jed Mahonis Group. If you're looking for a technical team who can help make sense of mobile software development, give us a shout at jmg.mn.