Mitesh Mistry is an Associate Partner over at IBM. In this role, he works with design architecture and helps customers understand how best to use the Salesforce platform to deliver their core use cases. 

Today I am talking with Mitesh about his long journey to becoming a Certified Technical Architect. In our conversation, he shares some great tips and tricks that he learned along the way. Tune in to learn from this developer turned architect who has been with Salesforce for years.

Show Highlights:

  • Why Mitesh transitioned from pure development to broader technical architecture.
  • The career value of working on user-centric projects.
  • What pushed Mitesh to become a Certified Technical Architect.
  • Why the journey to CTA is so long.
  • The nine domains of Salesforce.
  • What the CTA exam day looks like.
  • Why the exam isn’t knowledge-based.
  • Mitesh’s best tips for studying and preparing for the exam.
  • The importance of practical experience in the journey to CTA. 
  • Resources to help you on this journey.
  • Why study groups are so important.

Links:

Episode Transcript

Mitesh Mistry:
You need that human touch to be motivated behind what you do.

Josh Birk:
That is Mitesh Mistry, an associate partner over at IBM. I’m Josh Birk, your host for the sales force developer podcast. Here on the podcast, you’ll hear stories and insights from developers for developers. Today, we sit down and talk with Mitesh about his long journey to becoming a certified technical architect. He’s going to tell you little tips and tricks and things that he learned along the way. We’ll start, as we often do, with his early years starting with Sales Force.

Mitesh Mistry:
For me, it’s been Sales Force pretty much from day one, career-wise. I started working on the graduate program at Deloitte. This is back in 2009 and did a few months of Java development. I was helping the team build a digital rights portal. My first role involved using Java and Selenium to build unit tests, UI driven unit tests, ultimately. That’s how things began. Very quickly, within a few months I was like, this is getting a bit boring. Is there something else I can do? Low and behold, they actually purchased Sales Force, because they wanted to set up a community to allow for rights holders, performers, musicians to be able to reclaim their money, ultimately, for wherever the music has been played. This company basically did that on their behalf, using what was then known as Sales Force Portals.

Josh Birk:
Yeah, I think that’s right.

Mitesh Mistry:
Yeah. We built our community in there. My introduction to Sales Force at that point wasn’t the point and clicky stuff. Absolutely not. I was Mitesh, you know how to code, so you need to just make that. I was happily writing visual force paged and apex code to be surfaced in the community for these guys to submit their right holder claims.

Josh Birk:
Got you. How would you describe your current job?

Mitesh Mistry:
My current job is totally different now. I barely write code these days. I like it. I do like it. I want to stay close to it, but the issue I have now too many Sales Force updates have come out that I’m not okay with anymore. I might be more dangerous than useful, if I start to write code again, to say it really honestly. For me, my role is mostly around design architecture. It’s helping customers understand how best to use the Sales Force platform in a scalable and effective way to help deliver their core use cases. That’s ultimately what I do. It involves knowing how they work, knowing how they roll, knowing what they want, and understanding Sales Force functional and technical and best practices to deliver something of value for them.

Josh Birk:
Got it. Let’s see here. Long career, all of it in Sales Force, starting with the visual force days. Now, basically centered around technical architecture. Let’s talk about that transition a little bit. Was there a tipping point where you’re doing development and then you started getting more interested in broader technical architecture? What started to get you to transition out of pure development?

Mitesh Mistry:
Yeah, sure, that’s a good point. I would say it’s the change of jobs kicked it off, to be very honest. I feel that my role is mostly dev focused. I’m not going to criticize it. I think it’s just down to how they’re structured and what they expect people to do. When I moved to acumen solutions, I really got to do a lot more writer focused stuff. I think a lot of that is because the team there, I was [inaudible 00:03:42]. Which means that you’ve got a chance to take on more responsibilities, not just doing stuff and being assigned tickets, but actually working with the customer, talking to them, understanding their needs, being a part of design sessions, workshops, et cetera. To understand, from a much wider perspective, what they want to do. Building those soft skills, as well as your platform knowledge.

Mitesh Mistry:
At that point, again, with having smaller teams, you’re not just coding. You need to build the objects in Sales Force. You need to configure a report for a customers. A lot of these things you can’t just do in isolation. You need to be on the phone with them to say, “Right, I’ve done this report for you. Is this okay? Here’s how it works.” I think that got me introduced to a much wider range of the platform, let’s say. At that point, I was also starting to contribute to things like sales proposals, design documents, helping out with estimations. That just broadened my horizons a lot more in terms of what my specific role was involved in doing. That was a good two and aa half years there with acumen.

Mitesh Mistry:
Then, I moved onto Cloud Sherpas, which has now become Accenture. There, I would say it was a mixture of developments and also our architecture, as well. Helping our devs or instructing them, actually, what they need to build out, but spending a good amount of time actually understanding the existing core base, as well, before I can tell them, this is how you need to do things. There’s still a mixture of dev and architecture in those first roles, but I’d say the tipping point, honestly, would be when I joined Sales Force. I joined as a TA in Sales Force’s GSC group and my role there was pretty much no code. It was pure architecture. We always had developers who were in our offshore centers or by a third party company. My job was to then instruct them as to what they need to build, how it should they build it, et cetera. I wasn’t expecting to write much code. I did do little bits here and there, but it’s more for my own learning and interest, rather than actually being told, you need to build this.

Josh Birk:
Got it. That’s interesting, because I feel like that tipping point is a very common one. Even outside of going all the way to getting certified, do you think there’s career value for developers to try to lean into being more user centric and being on projects that are more user centric?

Mitesh Mistry:
I would say so. It also depends on where you’ve grown up, what regions you began your career in, and what kind of options you want in the future. For example, growing up in the UK and building my career in the UK, I would say we’re expected to take on architecture level roles as you progress your career. You’re not expected to be a developer the full time. Part of the reason for that is that we’re pretty expensive, as developers in western markets. We may want to build out at between 600,000, 700,000, 800,000 a day. Which, if you’re off shore, it’s a lot less than that.

Mitesh Mistry:
Then, at the same time, to be an extremely good developer locally, you’re competing with everybody offshore, as well, at the same time. I think, in the western markets, there’s probably more of a push to transition towards an architecture role. I’d say the same for those who are in offshore markets, who wish to have a more non-functional role or have more client exposure. The more you start leaning towards more architecture based disciplines, I think that’ll open doors for going overseas, being more client focused, and taking on those roles. That’s how I see that path shape up. Whether you are in a local market or whether you’re in an offshore center, when you want to transition to an overseas market.

Josh Birk:
Got you. Yeah, I’ll point listeners back to the interview with Rupesh Bhatia where his angle really was very focused on being an offshore developer. It’s very easy to just be that guy who takes a ticket, gets a ticket done, and then moves on to the next ticket. His whole take was if you can think and act a little bit more like a consultant, that’s one of the ways that you can really start to progress your career somewhat.

Mitesh Mistry:
That’s the nature. The second point I’d say to that, as well, is when you start going on this architecture journey and reading a lot of the Sales Force materials, which are out there, you learn a lot of things you didn’t know. That impacts how you ultimately deliver Sales Force solutions day to day. I’m sure we’ll go into it at some point, but the CTA journey and the learning for that, taught me a hell of a lot of stuff which I didn’t have to even think about or do hands-on reporting. I’m just like, wow, I didn’t know. Then, when you actually go on the journey you’re like, this is actually super important and I wish I knew this a few years ago.

Josh Birk:
Right. On that, and maybe it’s the same answer as you gave before, but I know a lot of people who have roles either in architecture or related to architecture, but being a CTA is that long term goal for them. When were you getting certified, that’s my goal, that’s something I’m going to get done?

Mitesh Mistry:
Okay. It actually started a long time ago, when I was at Acumen. We had a guy there who was one of the first few people, I think, to obtain the CTA. Just hearing the word CTA was like, wow, these are gold members of the Sales Force ecosystem. There were so few of them that you’d almost want to bow down and say, wow, this is the Sales Force guru. I need to ask him stuff. He knows what he’s talking about. That really got the ball rolling. I thought at some point, I have to do it. I was pretty slow about it, because I didn’t really actively pursue it too much or start studying for things. What I found is, just when I joined Sales Force, they released the whole trailblazer academy for architects with all the modules you need to learn and study, et cetera. They’re very nice structured formats. That was part of it.

Mitesh Mistry:
The second thing at Sales Force is we had the whole nine domains and nine different badges that you had to do. It forced you to go down a certain study route to be even able to appear for the CTA boards. I think when I joined Sales Force, the motivation was, let’s get this done as quickly as we can. Let’s go on this journey and really make it happen. I pretty much gave myself two to three years to say, keep your head down and just get studying and let’s get this done.

Josh Birk:
First of all, I want to just put a pin in that, because when we’re talking about the scope of what we’re talking about today, you knew from the get go that this was going to be a multi-year journey?

Mitesh Mistry:
Yes, absolutely. I think just looking at the kind of materials that I had to learn, hearing people’s stories from their experiences as a CTA and how long it took them to go through it, and also the transition you need to take from smaller projects and looking at things at a more enterprising and realistic level, it takes some time. It’s not a case of, I’ve been doing development for two years. I can do CTA and just study everything and I’ll appear for the exam and job done. You can’t do that. You need a certain level of project-based maturity just to understand, holistically, how things piece together to be able to then deliver a good solution on your keyboard. At the same time, something that I firmly believe is that the CTA exam is not just about this whole academic piece, but it’s also about on the day of the board, how am I coming across? Do the three people sitting opposite me feel that they could easily replace themselves with me and I could do the same job as they do.

Mitesh Mistry:
You have to give them that confidence. I don’t think that can come academically. You need to have done a certain role for a certain amount of time, to the be able to stand up confidently in front of three, let’s say, ruling judges and be able to defend your solution, as well, confidently.

Josh Birk:
Got you. Let’s take a couple steps back. I thought that was an interesting inflection point that the trail academy … is it academy?

Mitesh Mistry:
Trail head … let me get you the name. What do they call it now?

Josh Birk:
All I could think of was Trail Head University or something like that, but there’s been so many grants.

Mitesh Mistry:
It’s the technical arts at Trail, which they’ve launched. That contains all the child trails for all the different domains at Sales Force that you have to learn.

Josh Birk:
All right. Well, let’s pick up on that. What are the nine domains? Break that down for me.

Mitesh Mistry:
Okay. The nine domains, it’s broken down in a nice way, actually. It starts off with things like application architecture, where you look at the Sales Force object model, how it’s constructed, custom fields, formula fields, what kind of different types are there. A lot of the standard declarative stuff that you would build in the Sales Force platform comes under application architecture. There’s then the second domain, which dives deeper into the programmatic architecture side of Sales Force. This is looking at Apex, visual force, lightning, LWC, and all that fancy stuff that you can build to extend the capabilities of the Sales Force platform. We then move to community cloud, which is another domain to study, which is really cool. That was actually when Community Builder was fairly new at that time. It was really cool that you can just drag and drop stuff on and within two weeks, you have a customer based community. Oh wow, that’s pretty cool.

Mitesh Mistry:
What else? We have integration architecture, security and SSO, sharing and visibility, then mobile. I don’t know if I’ve mentioned nine there.

Josh Birk:
That sounds about right. When you’re prepping for this, it’s almost like you’re doing nine individual tests that all interrelate with each other when you’re going to go present to the board?

Mitesh Mistry:
Yes. There’s ultimately the solution that you need to present. It covers elements from each of those nine areas. For example, when you’re designing a data model for a particular CTA scenario, you need to understand the sharing implications of how your data model is designed and what does it mean from this perspective, as well. You need to think about are there any objects in here which are going to be a large data volume. If so, how am I going to manage that? How am I getting control of access to my objects, maybe certain users should not have access to certain bits of data and maybe certain users should. You need to tie in sharing your visibility into part of that. There may also be a need to synchronize data in an object into an internal system, in which case, integration architecture is relevant. The CTA exam, itself, really does bring together all of the domain elements that you’ve studied.

Josh Birk:
Got it. Walk me through. I’ve always felt like exam is such an understatement for how I’ve heard the day of actually goes. How does the exam flow? How are you presented with the problem? How long is it taking you to put that together? What’s the nuts and bolts of that actual process?

Mitesh Mistry:
Okay. Let me just walk you through what that day looks like, when you appear for the review board. You could either have a morning or an afternoon slot, firstly. If you have a morning slot, then they expect you to be up at 4:00 or 5:00 a.m. They’ll typically start your day about 7:30, 7:45. You’ll start solving the case study. It’s about three hours that people get to solve the case studies. It used to be two in our time. I’ve been telling people I coached that the extra hour is gold dust. Use it wisely. Still try and solve it in two, but keep the hour free, because you can use it to really enhance your solution and make sure it hangs and works.

Mitesh Mistry:
You start off with that. Then you have a small 15, 20 minute break while logistics are occurring. Basically if you’ve done anything on paper, it’s getting moved to the presentation room. The laptop they give you is being shifted across the [inaudible 00:15:07] to have you ready. After that break, you then present. That’s a 45 minute, judges all quiet presentation. The funny thing is, if you work at Sales Force, you probably will know one of the judges, actually, who are there. You can’t smile at them. They can’t smile at you. You just pretend you don’t know each other. 45 minutes, three cold faces just watching you saying, “Okay, fine. Talk about your architecture.” 45 minutes of that, then there’s another 15, 20 minutes when the judges are formulating their questions and formally re-reviewing what you put on screen, just to make sure everything is correct and what they want to grill you deep on. Then, you have the fun 45 minutes of Q and A, where it can go in any direction, let’s just say.

Josh Birk:
Like, I feel the sarcasm when you said the word fun there.

Mitesh Mistry:
No, it honestly can. If you have faith in your solution, you’ll no doubt defend it quite well. For me, when I went for the board … and I went twice. To be open about it, I went twice for my review. When I went the second time, I had a lot more faith in the solution I had put together. I really felt that I knew how it hung together and I’d be able to defend my choices, as well, when asked about it. I was comfortable at that point. If you have any maybes or ifs about your solution, it won’t take long for a judge to sniff those out. They’re going to grill you on that for a good little while, ’til you give them an answer that they’re happy with. That’s typically how it goes.

Mitesh Mistry:
What I’ll say to people is, they’re not their to fail you. They’re actually there to make sure you pass it. There are elements which are not clear to them or which, with a little bit of change would actually work, they’ll try and push you in that direction to make you successful, rather than to make you fail.

Josh Birk:
Interesting. I’ve always thought … and we’ll go back to the old word, but this kind of exam, they’re not throwing knowledge based questions, like do you know the proper limits to the apex cycle that would be used here. They’re digging into the corners of the solution you’ve provided and just trying to make sure that they’re actually the right edges that they’re looking for?

Mitesh Mistry:
That’s correct. It’s not a blanket knowledge test. You’ll never find a judge asking you, at least directly, tell me the limit for the number of emails you can send out of Sales Force in 24 hours. They’ll not ask you that. If somebody has come up with a proposal where, let’s say, you’ve got a million customers and then you have a bulk volume use case where you need to email a million people at any point in time. You suddenly say that the Sales Force platform will do it, no problem. Yeah, you’ve got a problem.

Josh Birk:
Yeah. Yeah. I love that specific reference, being somebody who has broken an application, because he thought apex was just going to send emails out all day. That’s the real thing. Also, I want to pick up on a point. They provide you with a laptop. Day of, what is your access to material?

Mitesh Mistry:
Okay. When you’re there on the laptop, in my time, it was Microsoft PowerPoint that was installed. You have Google Docs that you can write stuff in. In fact, I don’t think I could in mine. It might have just been Word. I think that’s all we had. It was PowerPoint, Word, and no internet connectivity. Pretty much no access to any materials. It’s just your case study, which you have a digital form and a paper form and you have your laptop to do things in. I think it’s changed now, as far as I’m aware, because there’s been virtual review boards held for the last year since Covid-19. That has now become a little bit different, the process, and how it can be done. There’s probably more tools around how they control security and how the board is done. Certainly, in my time, most candidates would do a split between doing PowerPoint and doing stuff on A3 sheets, on the paper, as well.

Josh Birk:
Oh, wow. Okay. Tell me a little bit more about that two to three years. When you’re coaching people, when people are showing an interest to this, what’s the time gap? What’s the sacrifices people should plan to set aside in order to get to that day of exam?

Mitesh Mistry:
Okay. Cool. That’s really good and definitely something that I should run through. For me, looking at my journey, it was focused, firstly, around going through each of the trail head modules that had been defined for each of the Sales Force domains. There were nine domains there. I obviously knew some elements of certain things, but I literally used to open each article, read it, and then make my own revision notes in Google Drive for that particular domain. I’m glad I did that. The reason I did that is because I knew that for the review board, I’m going to have to treat this as like an exam, in terms of what I should know. To keep memory at the top of my mind, the only way I can do it is by having condensed notes that I can easily re-read at a later point in time, rather than having to go through the whole set of trail head modules, et cetera, again. That’s what I did. Aggressively, I’d say, I spent a good year at Sales Force doing that, going through the nine badges that they had.

Mitesh Mistry:
Then, what at Sales Force worked really well is that we were asked to present, once we finished a certain domain. For example, you studied about integration. You might go off and sit the integration architecture research. Then you have to present internally for 30 minutes on a case study around integration, to ensure that you actually know your stuff. It gives the Judge a chance to quiz you as well and make sure you know the areas of that domain. What I’ve found is, sometimes with the multiple choice exams … it’s not a criticism, but sometimes you can wing it. When you have somebody in front of you, asking you a certain question and asking you to explain something, you can’t just choose option C and say you answered it. You need to physically explain something and it’ll be very clear if you don’t know something. I think that approach at Sales Force has worked brilliantly. Ultimately, you’re presenting nine times, before you even start doing mock exams. That approach worked really well.

Mitesh Mistry:
Yeah, for me, in terms of study, it was almost one to two hours every evening, going through these materials and making my notes. That was for a solid year, I would say, just to make myself knowledge ready. Not just reading stuff, but some of the module make you do things. Configuring stuff on the Sales Force platform, but also there are just little things that you might want to try out. For example, not many of us had been working on a project which involved single sign on, but you want to be able to know how to do it, ultimately, to be able to talk about it on the board. To do that, you then take a simple exam. Fine, let me try to link Facebook to my Sales Force community. That’s one use case you can try out.

Mitesh Mistry:
Secondly, let me try and configure SAML-based data SSO between two Sales Force orgs. Not just that, but to prove the point that I know what’s being passed in between those two orgs, let me open up my Chrome developer tools and just see, physically, what’s being passed from A to B, just to confirm that the training material is talking honest and things that are genuinely are passed from org to org. That was really helpful. It make sure that I knew my stuff, not just from a theory perspective, but from a certain degree of practice, as well. I can know how things work. Likewise, for integration. We speak a lot about integration patterns, how you can link SAP and Sales Force, how do you sync data between them. People don’t talk about the practical side of it to say, how will you actual ensure data’s kept in the sync. If a sync job fails, where are you going to report that. In the middleware? In Sales Force? How do you rectify those situations? That whole end to end design, you need to have done it once, either on a project or at least thought about it and implemented it yourself in your org to be able to then talk about it with comfort in the review board.

Josh Birk:
That’s a really interesting point and it’s something that in my years of having conversations with developers kind of constantly comes up. That there’s a lot of developers out there, they get in, they do the job, they go home. Maybe they don’t know apex rest was out there, simply because their job never challenged them to a point where they needed to go try to find a solution for things like that. How frequent was that, that you had to create that artificial version of an integration or something that didn’t exist in an org. You just had to recreate how a more complicated structure would actually be in place?

Mitesh Mistry:
Yeah. There were times when it was useful to actually do that and understand how things can work and piece together. Thankfully, for me, my first project out of Sales Force was an integration one. I got to understand how I can write apex call outs to make the call to an external service, get a response. Also, at that point in time, I got to understand the reason for using the apex continuation framework in those particular examples. It let me implement it, so then I got to understand the practical side of it and why it’s there and how it works, et cetera. That, for my project experience, was quite useful, but at the same time, if I hadn’t done that, I would have to have built some product to some form of service or some separate Sales Force org just to understand how that end to end integration can actually work. I think it’s important to get a bit of practical experience in those areas. They call it muscle memory, where you have things at the top of your head, because you’ve experienced it. Those things stick with you a lot longer than just theoretical knowledge.

Josh Birk:
Got you. Going back to that theme that you need to be able to stand in front of a group of three people and confidently explain something, potentially using a laptop that has no internet connection.

Mitesh Mistry:
Correct. Exactly. Also, at the same time, you don’t know what you’re going to be asked, as well. It’s better that you have knowledge both deeply embedded in your head and also available at the tip of your tongue, so that you can give a response when the question is asked.

Josh Birk:
Okay. You’ve mentioned trail head. You said that there were some mock exams. What are some other resources that some people might want to look at before they start going down this journey?

Mitesh Mistry:
Okay. The good news is that today, there’s a lot more stuff out there than was there four or five years ago. There’s a lot of public study groups. I noticed SAIMA is one that’s being run and EMEA. That’s a really popular one. As far as I’m aware, there’re a couple of things in the US which people have launched. Deepan [inaudible 00:25:44] has launched a book. [inaudible 00:25:47] Barry has launched a book, which I’ll talk about, Sales Force Architecture and CTA Journeys. There is, generally, a lot more resources out there now, publicly available, apart from the Sales Force modules, to help you then skill up and be ready for the review board exam.

Josh Birk:
Got it. How important do you think it is to find other people to help go down this journey and get involved in things like study groups?

Mitesh Mistry:
I think it’s really important. Sales Force, for me, it was nice to have a body of 120 CTAs who you could … let’s be honest, you don’t know everyone, but at least having three or four that you can ask a question to is super useful. From their experience, they can give you some insight into certain domains which you may not be skilled up on. They can give you a good answer on that. I have that. I wasn’t part of any formal study groups. I just leveraged on the people that I knew at Sales Force to help out. The external study groups are going to fulfill the same thing, where you can reach out to other people and just learn from each other to be like, fine, how are you presenting your nine slides? What are you putting in them?

Mitesh Mistry:
Maybe if you have doubts and questions. No doubt, as you’re going through the study material, you’re going to end up with some questions in some areas which you’re just not sure and you just want to bounce that off somebody to say, hey, what does this mean to you? How does this work? Maybe you can just explain this to me. When you get that explained, just like, oh, okay, that’s cleared my doubts. I think being part of some group is definitely useful in that CTA journey.

Josh Birk:
Tell me about two days. First, the day you realized you hadn’t passed the exam. Then, second, the day that you realized you had passed the exam.

Mitesh Mistry:
Okay. Yeah, I think the day I realized I hadn’t passed, it wasn’t a great day. You feel like, you know what, I’ve gone through two years of intense study and went for the review board, showed face. I think I knew, to be honest, that I’m probably not going to get through, mainly because I got grilled a lot on the data model and sharing. What I was told by my coach is that if you’re grilled in those areas, it’s not always a good sign.

Josh Birk:
The core is probably problematic, and it’s hard to rescue out of that?

Mitesh Mistry:
Exactly. It’s very difficult to then be able to either justify, defend it, or get it right. It’s a domino effect, where if you fail in the core domain, it knocks off everything else, as well. This is what I tell people I coach, where you might know your domains really well. You might be great at integration. You might be great at SSO and that’s fine. You may have presented those bits well on the board. If you mess up your data modeling and get that wrong, you’re going to get zero marks or at least reduced marks for those sections, as well, despite the fact that you actually are good at them. I always tell people, don’t get disheartened by the way the results come, because they’re not a reflection of what you know, to be honest.

Mitesh Mistry:
Coming back to your question, I wasn’t too pleased with the outcome. I think the first thing was reach out to find out where did I go wrong? What can I improve on? Yeah, I got myself together. Pulled my pants up, as they say, and started a seven month journey to re-appear for the review board. I said, let’s not give up. Let’s go again. I know I’ve learned my stuff. I spent a lot of time doing it. There’s no point giving up. Go again. Thankfully, my wife is quite supportive. She’s like, I’m not letting you out of this journey until you pass. Then I was like, fine, I need to just crack on and get this done.

Mitesh Mistry:
What did I do? I looked up all the new stuff that Sales Force had released in that time, because things had changed. I spent a lot of time looking at things I didn’t know, that I wanted to brush up on. That was useful. I also went through another set of mock exams. The same ones, but just redoing it in a different way. I changed my presentation approach and style that I was going with to the review board. That definitely helped, because I actually realized that I’m actually quicker at typing stuff on a laptop, compared to scribbling on paper, so I changed my approach, altogether. The combination of those things, along with just getting a bit more confidence, definitely helped me when I went to the board the second time.

Josh Birk:
Nice. How did it feel the second time, or when you actually passed?

Mitesh Mistry:
It was an awesome feeling. I saw my phone. I knew that within a two, three week window after the board, you get the results given to you. I remember checking my phone almost nightly. I work up at 3:00 a.m. and I saw the email. You don’t see the email details, you just see the subject. I don’t think it tells you anything. I was just like, I’m not sure what this is. I opened it and you read the first few words and like, yes, I passed. This is awesome. That was so cool.

Mitesh Mistry:
The interesting thing is, the time that I passed is just when we had entered a Netflix show called the Family Cooking Showdown. Yeah, I was on TV three years ago. You’ll find me on Netflix, as well, if you have a look.

Josh Birk:
Really?

Mitesh Mistry:
Yes. As a result, it was literally a case of finishing up CTA and going straight into filming scenes for a TV show. It was manic. It really was manic, but it was good fun, nonetheless.

Josh Birk:
That’s our show now. That was a little bit of a spoiler, because yes, Mitesh’s favorite non-technical hobby has something to do with cooking.

Mitesh Mistry:
It’s definitely cooking, for sure.

Josh Birk:
Wow, awesome. How did you get on a show?

Mitesh Mistry:
This is, again, an interesting story. My wife actually was running a food blog at the time, so someone reached out to her and said, we’ve got slots in this show. Do you want to take part? We thought this was just nonsense. Who the hell calls you up on the phone and then asks you anything like this? Where did they even get the numbers from?

Josh Birk:
Right.

Mitesh Mistry:
She took the call and she said, I don’t know if this is legit, but let’s see. Anyway, two days later, the production company gave her a Skype call and said, yeah, we’re doing this show. It’s called the BBC Family Cooking Showdown. It’s series two. We’re looking for contestants. Do you want to take part? They screened us. Made sure we’re … I don’t know what they actually screened, but they probably make sure you’re TV worthy or face ready. I don’t know. They make sure you can appear on TV and do some background checks and all those things. They also came to our house, did some recording in our house, just to get some background shots of us, et cetera. In May or June 2018, just after finishing the review board, we were straight in recording studios in Cardiff, going through different rounds of this cooking competition.

Josh Birk:
We will totally link to that show. It’s on Netflix, if you want to check it out and see if Mitesh and his family won the big family cooking showdown. Now, I want to thank Mitesh for the great conversation information. As always, I want to thank you for listening. If you want to learn more about this show, head on over to developer.salesforce.com/podcast, where you can hear old episodes, see the show notes, and have links to your favorite podcast service. Thanks again, everybody. I’ll talk to you next week.

 Get notified of new episodes with the new Salesforce Developers Slack app.