How To Interview With a Tech Giant: Part 3

Cloud network engineering interviews at tech giants require specialized knowledge beyond traditional networking – particularly when it comes to cloud-native services. In this final installment of our interview preparation series with Kam Agahian, we explore the specialized networking services that frequently appear in technical assessments.

Security takes center stage as we discuss the critical boundary between networking and security responsibilities. Kam explains that while routing traffic to firewalls falls squarely on the network engineer, security policies and posture typically belong to dedicated security teams at larger organizations. We compare traditional VM-based third-party firewalls with cloud-native security services, highlighting the architectural considerations for each approach.

DNS architectures represent another technical area where candidates must demonstrate proficiency. Beyond understanding traditional name resolution, you'll need familiarity with the hybrid cloud architectures that enable communication between on-premises and cloud environments. Kam singles out DNSSEC as deserving special attention during your preparation.

The landscape of multi-cloud connectivity has evolved dramatically, moving beyond simple cross-cloud connections to sophisticated integration patterns. Candidates who demonstrate awareness of recent developments – like Oracle's strategy of placing databases directly in other providers' data centers – stand out in interviews by showing they stay current with industry trends.

Throughout our conversation, we emphasize research as a critical interview preparation strategy. Review all cloud-related job postings at your target company to understand their technology ecosystem and identify potential multi-cloud scenarios. This contextual knowledge allows you to tailor your responses to the specific environment you'll potentially be working in.

What questions do you have about preparing for cloud networking interviews? Share your thoughts and join the conversation about navigating these complex technical assessments.

Connect with our guest:

https://www.linkedin.com/in/agahian/

Purchase Chris and Tim's new book on AWS Cloud Networking: https://www.amazon.com/Certified-Advanced-Networking-Certification-certification/dp/1835080839/

Check out the Fortnightly Cloud Networking News
https://docs.google.com/document/d/1fkBWCGwXDUX9OfZ9_MvSVup8tJJzJeqrauaE6VPT2b0/

Visit our website and subscribe: https://www.cables2clouds.com/
Follow us on BlueSky: https://bsky.app/profile/cables2clouds.com
Follow us on YouTube: https://www.youtube.com/@cables2clouds/
Follow us on TikTok: https://www.tiktok.com/@cables2clouds
Merch Store: https://store.cables2clouds.com/
Join the Discord Study group: https://artofneteng.com/iaatj

Chapters

• 0:00 Introducing Part 3 with Cam McGuigan
• 1:43 Cloud Networking Services Overview
• 3:32 Firewalls and Security Responsibilities
• 11:55 DNS Architecture and DNSSEC
• 21:51 Multi-Cloud Strategies and Trends
• 31:29 Interview Preparation Strategies

Transcript

Chris: 0:00

Hey everybody, it is Chris from over here at Cables to Clouds. Thanks for joining us this week for our episode. Unfortunately, tim is on some current overseas travel to Japan, so unfortunately you just got me this week. But luckily, today we are going to be releasing part three of our series with Cam McGuigan on how to interview with a tech giant. So if you kind of go back, um, look through the show notes if you haven't heard the first two episodes, they're really good on going over kind of the kind of the foundation to going through one of these interviews with the tech giant.

Chris: 0:36

Um, we get into kind of the bits and pieces about you know what kind of routing protocols and things like that you should be learning, what kind of skill sets you should be focusing on things like that, and in this episode we get a little bit further into it about additional concepts that you should be into, like load balancing, ipsec, et cetera, and overall I think it's a very good conversation, really fitting into a multi-cloud context as well.

Chris: 1:00

So with that out of the way, let's hop into the episode. Okay, yeah, so good progress. So you've kind of, you know, made it through this second interview where you're talking a lot about common networking constructs, and there's a lot of cloud nuance sprinkled in there as well. Let's maybe take it a step further and let's start talking about where you're probably gonna get some questions around the specific networking or networking adjacent services that the CSPs offer as well, right, cause there's a lot of those that are kind of brand new territory to a lot of traditional network engineers, right? So let's kind of go over some of those and the importance is there.

Kam: 1:50

Excellent. Exactly, it's quite a few services. So let's say, now you're done with the second interview, second technical interview. And for the third interview, I would like to know do you know knowledge when it comes to our services? This is a very broad topic and it varies from one cloud provider to another. Some cloud providers have extensive SaaS services how to get to SaaS. Some do not have any SaaS and some of them support services that do not exist in the other one, for example, native CDN, non-native CDN. All that to, I guess, find the kind of common grounds.

Kam: 2:29

I want to talk about some very common services, most common services that these days network engineers or cloud network engineers find themselves configuring or providing design suggestions even sometimes our case answering to RFP questions is the whole area of security how to secure your environment in terms of firewalls. That's one thing. The other thing is how is my whole name resolution process going to work in a cloud? So the DNS topic and the third one is load balancer. Traditionally, if you go back to your data centers, I would say pretty much all the three areas were kind of gray area. Some system app people wanted to own them. Sometimes they didn't want to. We would own part of that In a cloud. We still have the same conversation, but a little clearer. At least, when we work with customers, we try to make it very clear that let's take a look at firewalls for a second Extremely important, extremely important solution.

Kam: 3:35

It's really hard to find even a single customer these days doesn't want to use any firewall. But whose responsibility is that? Is it a network engineer person? Is it a security person? Is it a network engineer person? Is it a security person? Is it a CISA person? Is it your application or maybe kind of joint responsibility? I'm personally not a huge fan of joint responsibility when it comes to configuring a device like this, where we kind of split responsibilities is, there is a clear line and, by the way, this is how I approach this.

Kam: 4:08

There might be many other ways, I'm sure there are, but this is how I would approach this and how I shape my interview process is as long as you can route your traffic to the appliance, to my firewall, to that security solution, the networking person is done. Your job is complete. There is someone else who understands the bigger security posture, who understands how my overall security should look like. That person works with me to create my security policies. How I want to treat different types of traffic. What are major threats? How I want to react. Am I going to just permit and log? I want to deny types of traffic. What are major threats? How I want to react. Am I going to just permit and log? I want to deny Ingress, ingress. These are not kind of decisions that I personally want a network engineer to make.

Kam: 4:59

If you find yourself in a situation where you're making not just routing decision but also overall security posture, I would say probably that's like a little too broad sort of job description. But again, from my perspective, the standard way you look at the architecture, there are two general ways, and that also applies to the interview process. One of them is you create a virtual machine, vm shape, instance, different terminology and you load your third-party firewall. It could be a Palo Alto firewall, it could be a Cisco ASA, it could be a Fodder firewall, it doesn't really matter. You bring up that firewall on that instance and what happens there is. That solution would almost support, I would say, 98% probably of all the features that you had on your traditional firewall, pretty much identical to your firewall. This is, of course, this also needs your licenses and all those things that somebody else needs to worry about it, or you need to make sure it has licenses. That's how people would bring up firewalls up until probably four years ago, five years ago. There is another way and that's the kind of recent solution CSB is now offering their own firewalls and in most cases, deploying those firewalls could simplify your architecture with a little fine print that those firewalls might not support every single feature that you would get out of your full-blown firewall running on a VM. So you need to find out core features you need on your security appliance and whether the service, the CSP, supports that feature or not.

Kam: 6:45

Once again, as a network engineer, I do not want you to make that call and when it comes to the interview process, this is pretty much all you need to know about what's going on on that box. But how you route traffic to those solutions very much depends on your CSP. So you need to go back to documentation of that CSP. We have extensive documentation. I know AWS does, I know AWS does, I know Azure does, and they clearly explain how to capture traffic, how to kick it over the firewall, how to install the firewall in path or off path and how to process. How about a spoke model or something else? How to scale it? These scenarios probably are the most complex architectures that could come up when you're talking to someone for a network engineering role in the cloud how to architect and how to deploy appliances or CSP-specific firewalls. So that's a very important topic.

Tim: 7:46

Yeah, I think the routing thing is such a big deal, especially with the CSP native firewalls. I mean, unless you're like, for example, I know in AWS you have like the firewall endpoint which is basically a Gavi load balancer with a different hat on at the end of the day. So that's just a matter of orchestrating a route table to point at the load balancer.

Kam: 8:04

But yeah, in general it's a big complicated routing thing.

Tim: 8:06

but yeah, in general it's a big, complicated routing thing probably that's the most complicated topic, I think to your point.

Chris: 8:14

If you're interviewing specifically with someone that is at this scale, I highly, highly doubt they're going to have individuals sharing the same hat of networking and firewall management. I would certainly hope so if you're doing both Not a tech giant.

Tim: 8:31

I take pity on you for sure. I worked enterprise where I did firewall, network, collab, data center. You love collab. I did every single. I did all of them, including collab. But that was an enterprise, man, an enterprise. All bets are off. Right, we're talking about a tech giant A tech giant? Probably not. That's not going to happen to you at a tech giant.

Kam: 8:51

When was it 1999?

Tim: 8:54

No, not that long ago. This was back in 2015-ish, so yeah, it wasn't too bad.

Kam: 8:59

Oh yeah, yeah, we all have one of those jobs. But these days, I guess the amount of knowledge is so vast it is you can't really expect a single person to track all your security threats, all the vulnerabilities and everything else. Again, we're talking about overall security posture. I'm not talking about a single policy. How to configure that that's probably the least important thing how that single policy is going to work with your overall security posture. Track that plus the entire network. This is a little big for even one team, so it has to be a little separation of responsibilities here. So that's the topic of security.

Kam: 9:40

Again, two flavors. Make sure you know which CSP you're talking about. And good news is they all publish their architectures. And again, another good news is unlike publish their architectures. And again, another good news is unlike I gotta be very careful here unlike traditional networking, you cannot get super innovative and creative. So there are not a million different architectures that you could create around that, around the service in on that CSP solution. You could create around that CSP solution. You could make some modifications, you could kind of update it, customize it a little, but it's not like you can just blow it up and then rebuild the architecture the way you want it, completely different from what they recommended. So extent of that architecture is limited to what they recommend plus minus, probably 10%, 20%, but again that's most likely the most difficult question that could come up. But again, there's documentation out there and there's not going to be a lot of modifications to their architectures.

Chris: 10:41

Yeah, totally yeah. There's usually two to three ways to get something done and you're not going to see much variance there without doing a lot of work over the top, which is just going to add a lot of overhead. Uh, complexity for you, but I think I think you call it a really good point in that one of the major things about working in cloud is going to have to be around third-party integrations, um, because you're not like you know some people, some people do like look, I'm only using the CSP native services and I'm never using anything outside of that, um, but there that comes at a, at a, at a pretty penny, right, Um.

Chris: 11:19

So you know, sometimes you you do want to stick with, um, some other, uh, alternatives, alternatives, you know, maybe you want to use Fortinet or Palo for your inspection, just because the price point is so much better, right? So I think that is super key in integrating those third-party solutions, and what are the drawbacks and what are the advantages?

Kam: 11:39

Oh yeah, the management plane how you want to manage those you know, monitoring, how you want to receive logs and process, so it all matters. That's just a very interesting topic. The next kind of service is DNS and name resolution. Once again, there are two possibilities here Traditional DNS knowledge around DNS, dns theories. You need to know that. So if you're talking to someone like me, I would love to go back. I want to go back to the days we had host file, we had lm host, we had wind server how do you bind?

Kam: 12:15

here we go. We had, we had bind, and then we upgraded the bind. Some bind would work with active directory, some of them wouldn't, and then without integration, active directory, and then, and then, and then we get to a point where now we have the csp and and now in the CSP you have your name resolution process. It's a very straightforward thing. If you want to stay within the cloud, most customers they want to have name resolution between the cloud and what they have on-prem, and that introduces you to the world of hybrid architectures.

Kam: 12:47

Same recommendation that Chris and I were talking about again applies in this case Every CSP. They have their own set of architectures, clearly published and through some recommended solutions and best practices. There's not going to be a million variations of those. You could make some changes to it again, plus minus, maybe 10%, 15%, but at the end of the day, if, for example, you're preparing for OCI or Azure AWS, you look at your architecture for hybrid name resolution. 90% of the architecture is right there. So if you're preparing for those interviews, get a hold of the documentation, whiteboard it many times I would say at least five times, and you will see how, on one side, you're going to grab that query, kick it over to other side, resolution and back, and it remains the same across. But you need to know those. You know maybe two or three architectures per CSP.

Tim: 13:43

I got to give a shameless plug here. Steve McNutt did a really great chapter in our AWS advanced networking guide that we just released on DNS on-prem hybrid in-cloud and all of the endpoint resolvers. He went way beyond what was necessary. Yeah, it was great.

Kam: 14:05

Absolutely, absolutely. So. That's another interesting again topic and cool thing is you have the architectures. You need to spend time mastering those architectures and that is pretty much it around DNS. There is one little topic here that's not trying to scare anyone, but I got to tell you this. It's DNSSEC, and DNSSEC is one of the topics it's. It's kind of a little more complicated than traditional dns. You gotta know the theories, you know how it works and be prepared to spend some time there. I would say maybe five, six hours. Read a few times, try it. Two key, two key questions why and how? Why am I using this? How does it work With DNSSEC? You want to know under the hood, the records, how it changed, how it's improving my overall security and that kind of details. It's an interesting topic. That kind of details. It's an interesting topic Now that you're running out for your book.

Kam: 15:17

In my book also, the DNA sex section took a lot of time because I would write it, I would ask somebody else to read it. I was like what are you talking about? This is simple and again, I would simplify and simplify and simplify. So five, six iterations of the same chapter until my third party looked at it and said okay, this makes sense. I think I know how DNSSEC works, so be prepared to be a little challenged. But if I were to challenge you by asking just one DNS question, that would be probably DNSSEC and one of the architectures around name resolution.

Tim: 15:50

So I had forgotten until that very second Cam, that you also had written a book for the ANS on the same topic. Oh yeah, on the same topic. So this is actually kind of funny, right, it's like everybody on this podcast right now has written a book on the advanced networking specialty certification.

Kam: 16:11

Oh yeah, that's, that's. Uh, this is pretty cool. Uh, little in that book. I did not want it to be like this, so my intention was I'm going to have set of questions, I'm going to have a set of scenarios that people are going to look at this and I'm going to have 200 mini scenarios and my intention was to have small scenarios maybe 200 of them and that's how I'm going to explain topic of cloud. And then I kind of changed my mind. I'm going to do something like this I'm going to have one big scenario and that scenario like 40 pages, and then 50 pages of description and how things are done. I actually did that and then later I decided to make it free, available to everyone. If you look for that PDF file, you can find it. It's a CCDE-style cloud engineering scenario that I published three years ago, four years ago, and I never no, I never sold it and it's free out there. Take a look and it walks you through the chaotic organization that people are having problems trying to do migration to cloud and they fail.

Kam: 17:18

And then the last version of it was, you know what, not this, not the other one. I'm going to do this. I'm going to have questions like a set of questions, three or four sets of questions, but I like bullet points. I understand bullet points a lot better than I understand any kind of text. I grab my text, whatever I wanted, to write all the paragraphs and I turn them into bullet points. So some people like it, some people don't like it, but I personally, when I see things in a very organized way, with all the invitation, I get the topic better. So that's how I arrived there and we have that final version of that book. But I read yours as well.

Tim: 18:00

It's pretty cool, thanks man, I appreciate that, yeah, well it's funny because I had completely forgotten about that because when they first asked us to do it, we I was looking around.

Chris: 18:14

I was like. I was like I'm sure someone else has done this and dude, you were the.

Tim: 18:15

Yours was the only game in town at that time. Yeah, no, yours was no, which I was fine with. I was like oh cool.

Tim: 18:19

I was like I, and then I was like I kind of want to get it, but kind of don't want to get it because then it's going to like mess me up when I'm writing mine or something. I didn't want to have it do that. So now that I'm done with that book, you've now reminded me. Now I want to go back and check it out. We need to get into the show notes.

Kam: 18:36

So long story short, the DNS section of it took a lot of time because the topic by itself was pretty, I guess, dry and to some users difficult to understand. But I chewed on it many times. Four or five iterations later it's now easier to understand. Anyways, if you've read it for the first time on anyone's website and you feel it is difficult, it is.

Chris: 18:59

It's a little more difficult than other than the traditional dns, but four or five hours later, if you spend time on it, it's really nothing unusual yeah, I think, um, just to kind of echo home on that point you call out specifically, you know obviously DNSSEC is a huge topic and you know the concept of DNS architecture is about public versus private. I don't know if this is exactly what you even mean by that. But one thing that was also kind of huge for me was understanding kind of the network architecture for how you speak with DNS or how you resolve things Like with local resolvers and like that can be distributed in certain manners, like I don't.

Chris: 19:41

I you know obviously. I know AWS, probably the best in that scenario, but I know Azure and probably OCI have the similar constructs right and it's there's nuance to everything.

Tim: 19:50

It's a lot of networking to get DNS to work.

Kam: 19:53

Absolutely, absolutely. And DNS you need to know the theories, you need to know DNS in general, name resolution in general and it reminds me of that Nanook talk. You type in an address in your address bar, hit enter, walk me through the steps. And a good part of that discussion and of course the interviewer's answer was what happens to the name resolution part of that. So all those things still exist, plus the hybrid scenarios, plus the NSSEC part of it.

Tim: 20:27

And there's such a big part of cloud too, like there's all the services that are getting spun up on the CSP, like most of them have some kind of randomly assigned like DNS name that you know other services can refer to, or like you know that are just become part of the process you know way more important than it was on prem.

Kam: 20:46

And it's getting a little more complicated as we enter the multi-cloud sort of territory, because now we're talking about my stuff in someone as a CSP, someone else's in another CSP's data center. And you're trying to resolve names.

Kam: 21:05

So we actually have a blog post on that one, but there are those scenarios. We actually have a blog post on that one, but there are these scenarios. But again, for a job interview, unless you're interviewing for a very senior level role, I guess the interviewer should not go there. You need to know how DNS works, you need to know those hybrid architectures and I expect you to know DNSSEC maybe a little more, but that's pretty much the extent of you know safe knowledge to approach um job interview for this role for sure, oh speaking of multi-cloud.

Kam: 21:56

I mean that's obviously a huge connecting to clouds and you had AWS, I had OCI, somebody else in Azure wanted to connect this too. Somebody else had GCP and we talked about IPsec. We talked about, you know, equinix, megaport, different ways to connect those cloud providers to each other and give you like a fabric. Today, I guess, starting maybe about two years ago, year and a half ago, two years ago CSPs are kind of embracing each other's solutions. I've got to be very careful here. One example is Oracle databases.

Kam: 22:36

Now can be, physical databases, like we're talking about Excel machines in somebody else's data center, in this case AWS, azure and GCP data centers, so you can consume Oracle databases with all the good stuff that they had from within your Microsoft data center. So that's the new kind of notion of multi-cloud. When we talk about multi-cloud it's not just connecting the two clouds. So there are at least from my perspective, there are three flavors out there. One of them is you connect the two cloud providers using a third-party solution Equinix, megaport, someone else, or your own IPsec tunnel. The other one we had dedicated connections to other cloud providers. We had one to Azure. We had one to GCP not just physically one, that as a solution and then this new one that is placing databases in somebody else's data center and physical machines in somebody else's data center. So these are three kind of interesting architectures.

Kam: 23:39

Why would I notice when I go to a job interview, you could easily impress me as an interviewer as someone who studies look at the news, knows what's going on. Someone who studies, look at the news knows what's going on. You go a little beyond. You know Cam's or Tim's or Chris's book. You go a little beyond what's in that configuration file, what's in the console so you know the latest that's happening out there. You could absolutely impress me if you could share. Well, for example, in this region it is available. Not available. Going to be up in this region in maybe six or 12 months. That tells me. You know that kind of stuff. But multi-cloud is a quickly changing space. I expect to hear a lot more in the next 12 months, but this is unbelievable. This is absolutely unbelievable. Three years ago this didn't make any sense, but today it's a reality.

Tim: 24:36

So on our news episodes which we do every other week, of course, we've been reporting on Oracle's kind of multi-cloud partnerships for a while and I think our kind of thought about it was like, oh, do we lose Chris? Oh, brilliant, I'll just keep. And our thought about it was basically like, hey, what a smart thing for Oracle to do. Having been a little later to the game as a provider, it makes sense for Oracle to reach out and provide essentially the Oracle experience or the Oracle databases, or whatever and just partner with other CSPs.

Kam: 25:18

Absolutely, absolutely. Oh yeah, if you're already using somebody else's IES services. You built a lot of infrastructure somewhere else, but you love your Oracle database performance on-prem. Now you could get it from within that CSP. I just talk to them. They provide an offer and you can use our hardware placed in someone else's data center.

Tim: 25:42

Yeah, I think that's really cool.

Chris: 25:44

Yeah, so the multi-cloud piece is a very interesting thing and I think if we're talking about the concept of specifically interviewing at a tech giant, this kind of differs.

Chris: 25:54

You know whether or not you're talking about a CSP, a cloud service provider, or you're talking about just maybe a very large enterprise type deal.

Chris: 26:02

Right, because I think in some of those scenarios like the on the on the enterprise side, you know, if you want to kind of I mean, this is my, this is my opinion but I think if you want to kind of do some research ahead of time to determine whether or not you know they're, they are a multi-cloud environment Um, if it doesn't say it in the job posting, some telltale signs that what we've seen that usually lead to something like that is, um, big acquisitions. Uh, acquisitions usually mean they're acquiring another company that already is in one cloud. It may not be different or may not be the same one that they're using today. And you know kind of another one that I see a lot is you know if a company has done a lot of maybe posts or you know kind of general initiatives to kind of decentrify is that a word? Decentrify, like mitigate risk, is where I'm trying to take this right, so kind of distribute risk and avoid, you know, lock in with one specific environment or one vendor, things like that.

Tim: 27:05

Oh yeah, yeah. Avoid vendor lock in, yeah sure.

Chris: 27:07

Yeah, but I mean it's not really just avoiding lock in, I think it's more about kind of mitigating risk Getting the guts up before yes correct.

Tim: 27:16

Yeah, that's fair.

Chris: 27:18

Yeah, and I think one last thing was around business agility as well, right, Because sometimes you know certain clouds bring things quicker to market than others and that fits, you know, kind of the business case. So I think those are kind of some important things to focus on, at least on the enterprise side, from what I can tell. I don't know if, Cam, if you feel that's the same on the CSP side or where you guys typically straddle that line.

Kam: 27:45

Totally. Oh yeah, we kind of talked about it as well. Oh yeah, we kind of talked about it as well. So this multi-cloud concept sort of started with that locking concern that I don't want to be using just one cloud. I want to have DR in a different cloud. Well, one level up. And now, well, maybe the other cloud offers some services that my original CSP doesn't. How about I use some of their services but consume some other services from the other CSP? And it is an absolutely growing trend.

Kam: 28:19

Like I said, it's very important that you spend some time not on that particular job description you're applying for, but also their other job descriptions they posted on their career website. It's so important I just can't emphasize enough. Go to that website, look for keywords like cloud. They might have one CISO job posted. They might have one application person posted job posted. They might have some security or anything else related to the cloud posted In those job descriptions. I'm sure you can start fishing for keywords. Sure you can start fishing for keywords if you know this is well your role. You're being interviewed for aws or oci or azure, and in other job description you come across. Well, there's gcv here. So there's a great chance that this customer is a multi-cloud customer. Or you're going through your cloud network engineering job description. You don't see anything on flow balancers, for example. But you go to the other one when you look for keyword cloud and you realize, wow, these guys are also hiring application people or application or cloud application specialists, and in that job description there's a lot on the load balancers.

Tim: 29:42

Right.

Kam: 29:43

Although they might not directly ask questions on the load balancer, ask you questions on the load balancer, but who knows, there might be questions kind of related and those scenarios are pretty common. Just to give you one example, there is a. There is actually one of my favorite scenarios. Let me just spoil it here. Um, you have a little balancer. You're sending traffic to some back-end servers and all of a sudden you realize, wow, one of my back-ends getting a lot of traffic unusually high. You do your due diligence, all inspection Turns out there's some kind of NAT going on at the source, whoever that source is, and your load balancer is just pinning all the traffic to one particular backend.

Kam: 30:28

You're able to explain that chain? It is a network engineering task. I don't expect my application person to know how NAT works, how my inner traffic works, how it's routed and why he's getting all the traffic into one device. From their perspective, this might be something as simple as well. Look at this source and destination. It's generating a lot of traffic not knowing there are 15,000 machines behind that source and destination.

Chris: 30:58

Totally yeah, that's Well the idea of yeah, source and destination. Totally yeah, that's.

Tim: 31:01

Well, the idea of yeah, sorry Chris the idea of juggling, of understanding the tuples that can cause that kind of flow pitting to happen, that's very much a network engineer type of task. Yeah, I would not have expected an application person to understand the tuples.

Kam: 31:17

That's one example. If you don't see load balancer in your job description, but it is in somebody else's job description, it could be related to you as well.

Chris: 31:26

All right. So, man, this has been quite a journey. So we've gotten through pretty much a three-part series, all kind of talking about the process of an interview that you will go through for, specifically, a cloud network engineer position at a tech giant. So I think this has been great. So, you know, we've gone through kind of some really foundational elements as far as technology and even venturing into things like talking about the research that you need to do as an individual about the company that you're applying for. So I think this has really been insightful and you know, if anyone has any questions, definitely reach out. But, cam, I want to give you the opportunity to give us any closing thoughts that you may have about the entire process.

Kam: 32:08

Really, not much left. We've talked a lot and covered a lot of ground. Usual thoughts Number one do spend a lot of time not on your job description, on other job descriptions of the company. Find out what they are hiring, what they hired recently. Take a look at some people's profiles and what they're doing. What are their recent projects? What are they excited about? What are the keywords?

Kam: 32:33

That's another important thing and in these talks, what we did was we gave you a lot of pointers, we gave you a lot of keywords, but we did not get a chance to explain everything. I mean, we're not supposed to. We did not create this podcast to teach you basics of BGP or teach you how OSP works. But if you hear these keywords, just take a note. Go back to your resources. It could be your book. You want to look them up? Note, go back to your resources. It could be your book. You want to look them up? Great, you want to use AI? It's fine, and educate yourself on those things.

Kam: 33:07

Pretty much every single point that we brought up today and previous episodes. Those are important questions. These are questions that we've seen before and if you grab one of those keywords, you're starting a chapter. You come across something that you don't know. Go on, just keep going and educate yourself. Those are important topics. So we tried, really tried our best to cover the most important topics and it was just 100% meets like very, very lean. So good luck, and there's going to be future episodes, some other topics, but I think for cloud network engineering, we covered what we wanted. I'm happy with the outcome. Thank you so much, tim. Thanks, chris, for spending time and recording these sessions.

Tim: 33:56

It's been great man. This has been great. This has been so useful.

Chris: 33:59

Like you said, I don't think we've we're not going into the kind of deep in the weeds on the technology, but I think that people should be able to leave this with a strong syllabus to follow to make sure that they're prepared. So, if anyone has any questions, feedback concerns, our inbox is always open, so reach out to us and yeah, we'll see you next week.

Kam: 34:21

Wonderful Thank you.