Tim: 0:01

Welcome to the Cables to Clouds podcast, your one-stop shop for all things hybrid and multi-cloud networking. Now here are your hosts Tim, chris and A**.

Kam: 0:13

Hello and welcome back to another episode of the Cables to Clouds podcast. My name is Chris Miles at BGP Main, on what is it called? Blue sky, blue sky. And then uh, joined as always. Is uh or joining me as always as my good friend Tim McConaughey at Carpe DMVPN? Is it?

Tim: 0:30

Carpe Dash DMVPN. It is, it's Dash, dmvpn. Maybe I should get rid of the dash, because then you have to tell people there's a dash. Yeah, I don't know.

Kam: 0:37

Yeah, no, nobody wants the dash. That means you just weren't. You weren't the first to do it. But yeah, so we have a special episode for you today. Joining us is a returning guest, cam Agayan. Did I get the last name right?

Chris: 0:53

That's very accurate, yeah.

Tim: 0:56

We're big on accuracy here.

Kam: 0:58

Yeah, before we hit record, he was telling us that there's multiple pronunciations to his last name, just by his two kids already.

Kam: 1:07

So I'm glad I'm at least in the ballpark. But yeah, we wanted to bring Cam back on because, you know, obviously Cam's been pretty prominent in the cloud networking space specifically, which is a, you know, a very niche thing. We have a whole podcast about it, but it's a very niche topic and we wanted to bring on Cam to kind of talk about a topic that he's been in the public spotlight talking about a few times, and it's how to interview or how to prepare for an interview with a tech giant. You know, I think he's got a couple of articles out there on packet pushers, about how to break into a cloud network or a cloud engineering role, and then some YouTube videos on the same topic. So we wanted to give an opportunity for Cam to kind of go through that with us and we'll see exactly what we can come up with to help you guys out there preparing for interviews and things like that. So, cam, I know, like I said, you're a returning guest, but I'll give you an opportunity when you go ahead and introduce yourself.

Chris: 2:03

Awesome. Yeah, thank you so much, chris and Tim. Thanks for having me again. Well, as you mentioned, my first name is Cam and, as a senior director of Oracle Cloud, I work with many customers and part of our job, of course, is to interview candidates, onboard them and add them to our teams and, as you mentioned, and add them to your teams. And, as you mentioned, I've done some work on interview processes, how to optimize those same questions, how to improve the quality of questions, not just in client engineering, but also in general, traditional network engineering.

Chris: 2:40

Some of the, I guess, most popular blog posts I've published or videos that I always get questions on. There are some talks out there that I've done in the past, like how to do like IPv6 and some NPLS thing. No one ever asked me a question, but the interview related talks and videos. I always get questions Few times a week. People reach out, they have questions, they have feedback to share and sometimes the good news, sometimes not so good news, but anyways, constantly people talk about it. That's one of the interesting things. Actually, I'm very glad that those talks and blog posts help some people. So, yeah, the work is out there. It's been pretty popular.

Kam: 3:22

Awesome. Yeah, that's great. I know I've gone through the talks you did, I think the one about cloud network engineering specifically, was that an analog that you put that talk out?

Chris: 3:34

That was one of the nano talks. That is right. Also, you know a couple of blog posts on that. That's what I published. Also, I have a couple of books out there and part of those books I covered a whole bunch of questions on how to prepare for interview processes. In addition to that, I guess a part of my job I've done I guess over a thousand interviews for both Amazon and Oracle and, yeah, totally enjoyed those. Same topic network engineering and most recently cloud, but networking for quite some time.

Kam: 4:11

Awesome. Well, yeah, I think between the three of us. I mean, I won't speak for Tim, but I don't think I've interviewed nearly as many people as you have been, but I know we've all been on both sides of the interview experience many times, either giving them and receiving them, so I think we'll have plenty to talk about. So to get started, I guess you know I would say, why did you feel the need to put something out there on this particular topic and what's kind of an overview that you think everyone should know there?

Chris: 4:41

It's a great question, great question. Well, let me go back to the point you just made right Sitting on both sides of the table as a candidate when somebody interviews me. I'm into many interviews as a candidate and at some points, seriously, I wanted to write a book about it and to share my experience. This is how things went wrong and these are the things that I really liked. Oh, I let that pass, but I put my notes together, turned them into blog posts or other things and, of course, incorporated them in my talks. So that side of experience was really well eye-opening, I guess. And also, I interviewed many people.

Chris: 5:21

I saw people's reactions, questions that people get right, questions that people get wrong and, more importantly, questions that we ask myself, I ask and later turn out to be 100% useless. Why did I ask this question? I mean, it's a great question, it's a trick question, but what's the point? Or questions that I never ask. And I left the interview like 48 hours later I was like, wow, I wish I'd double-checked this point, double-click here. So, yeah, you know, sitting on both sides of the table is, of course, a huge advantage. That's why that's one of the biggest motivations and, of course, the entire goal here is the entire goal of the hiring process is to have successful teams and happy customers. So, yeah, that really matters to me. Up to you know this day.

Tim: 6:18

Yeah, it's. I haven't done a thousand interviews, I know that, but I identify with the, having been on both sides of the table. It's funny because when you're doing it, you want to be, um, you want to be fair, like you know, when you're interviewing other people, cause you remember, of course, what it is like being on the other side of that table and so, but at the same time, you still have a a duty and responsibility to your organization. You know what I mean. So balancing that is such an interesting thing to do.

Chris: 6:48

Oh yeah, that's 100% true. Yeah, I've been to interviews. I interviewed people. I clearly remember I'm not going to give you the year, probably people are going to find out but I asked a candidate question on inner VPN connectivity, like option A, b and whatever. It was the one with the RAS reflectors.

Chris: 7:06

That question was totally unrelated to the job, but I asked it because it was on his resume. You know, later I thought about it why would I even ask it? And he completely did not get it like, totally failed. But he could have passed the interview. He failed just because of my at this point I believe unfair question. But same kind of question somebody asked me and I totally enjoyed it because it was related to that job.

Chris: 7:32

I went I'm into one interview and the interviewer asked me just one question. Grab the marker, here's the whiteboard, show me CSE carrier, supporting carrier, and I have a couple of questions on the traffic flows and that was it. We talked about that 45 minutes and I totally enjoyed the discussion, as long as it's related that case it was. But the question that I asked was not so, reflecting on that, not really great question to ask. So, yeah, that was again another reason I decided to come up with at least my own best practices, my own question back. These are the things that I expect candidates to know and this is how I would like candidates to approach at least my own interviews yeah, that's a really good.

Tim: 8:13

That's a really good point, although I've I've, uh, some, some friends of mine you know that I've worked with and they've done interviews. They're of the opinion that, basically, if it's on your resume, if you, if you, if you claim to have expertise in it, that it becomes fair game. But I'm, I'm a little bit on the fence on it myself actually, because I know what you know. Like I'm with you on the the what I'm asking a question that doesn't have anything to do with the damn job I'm hiring for. Yeah, I don't know.

Chris: 8:37

I mean. So I've been to one interview. We interviewed someone as a panel and totally technical interview, 100% technical, and the candidates you know that role only required English. English is main language, just English, right. But the candidate also had other languages, including German, on his resume. One of the interviewers paused the interview, asked him to order breakfast in German and he could not. And the interviewers paused the interview, asked him to order breakfast in German and he could not, and the interview completely went sideways. So he still today. It's been years, but whenever I think about it I feel bad for him. And you know our overall strategy. I still can't admit, tim, to your point. I'm still on the fence. I don't know. I mean, was it a good question? Was it like an appropriate question? I don't know. It's still.

Tim: 9:25

Um, yeah, I mean there's some response. The interviewee bears some responsibility because if I hand you my resume and I say this is my expertise, it kind of opens me up as the you know, to basically be asked about anything that conceivably could be on that resume that I claim expertise in. So yeah, that's why I'm saying I'm a little on the fence about it, but I kind of tend towards yeah, it's probably better for all parties that we focus the interview on whatever the hell I'm hiring for and that skill set, I guess, exactly.

Chris: 9:55

That's very true. That is very true. I totally agree with that. So I reviewed your previous podcast. I totally enjoyed that.

Chris: 10:03

When Chris contacted me and we came up with the topic, he said oh, this is the topic you want to talk about. I had my own reservations. This is one of those topics that over years I thought about it many times what am I going to do about this? So I've done other works on network engineering, traditional network engineering. That's something that I can prep a candidate for. It's very classic. I can show you here's the TCP, here's the IGP part, here's the BGP part, and if you're working for a service provider, probably you need some MPLS. You're going to be fine 90% of cases. Even I can probably guess 50% of your questions. However, when it comes to cloud engineering, it gets a little tricky and that is why I was a little hesitant to get back to Chris on this one. Eventually, we decided to come up with a little agenda. These are the topics that we want to cover. The reason I was hesitant. Number one this is a very broad topic. I'm not sure if I want to call it a disclaimer, but at the end of the day it is a disclaimer. It is a very broad topic. I'm not sure if I want to call it a disclaimer, but at the end of the day it is a disclaimer. It is a very broad topic.

Chris: 11:05

So when you want to work as a cloud engineer, cloud network engineer or security engineer, it is not limited to one field and you could easily end up working on some other fields. Network engineers, traditional, you know, for example, you're not going to be responsible for details of load balancers. Most network engineers are not Application people. Systems engineers or other folks do that. Same applies to security. Most likely you're not going to be installing, managing or operating firewalls, but could be part of your job here. So that's one thing that makes it very special. The same applies to other services DNS and DHCP. Well, early 2000, probably at some point, we were responsible for services like DNS. But today most network engineers in enterprise or larger organizations they're not responsible for services. But here you might be. That that's one reason.

Chris: 12:01

The other thing is this conversation could easily get like very vendor specific when you're preparing for an interview with a, a company. It could be a vendor, could be an integrator, could be customer, an end user customer. They most likely care about their own services. When we well, I interview people, I give people options, just like coding. Coding I don't really care if you want to code in Java or C or Python, it doesn't really matter, as long as it works. I apply the same logic here, but I know there are people out there and they ask very specific questions because they care about it. They want to know, for example, if you know how this particular endpoint works well, how this particular NIC or VNIC works.

Chris: 12:49

But for the sake of this conversation, what I decided to do is, if you agree, let's keep the conversation focused on IaaS services and we're going to go after more general topics, things that are not very vendor-specific. We know there's plenty of SaaS options out there. We could talk SaaS wherever. We could talk PaaS wherever. We know, if you get into the vendor, the nitty-gritty stuff, it's going to be a never-ending conversation. There's a lot of good stuff there, but just for this session, we're going to focus on IES and not vendor-specific Topics that we know in general and kind of apply to every single vendor out there, every single CSP. That's how we're going to navigate through conversation this time.

Kam: 13:33

Makes sense. Okay, understood. So I mean, is there do we specifically want to talk about, like, is there a specific role that we're talking about here? Because I know there's several, obviously several, options out there, but, like you know, each tech giant has their own version of what they call a certain thing, right? So what does that landscape look like to you?

Chris: 13:54

That's a great question. That's a great question. I won't get to that. But now we're talking about tech giants. So the difference here is smaller customers probably can look at the job description and you can find out what you need to know On the tech giants. Let's say you want to work for a CSP or major hyperscalers.

Chris: 14:14

There are two different lines of business here and pretty much everyone's the same. One of them is how the cloud is built, how cloud is operated. That discussion is more traditional networking. You're going to have stn, you're going to have salampios, you're going to have a lot of routing, you're going to have probably isis or spf and then you're going to have bgp. All these things together plus all the virtual machines and all the visualization going on. That builds what is the cloud. That's one part. The other part is the result of that, the outcome of that whole big box. That's what we offer to the customers and on that part, actually the cloud's already built and the offering is the cloud. We will be more leaning toward the networking part of that, or networking flavor of that, although there's going to be a lot of overlap, as you will see, with security fields, with applications, but we will do our best to remain focused on the networking part.

Kam: 15:13

Awesome, totally makes sense. Yeah, I mean just like you said, like traditionally, probably, network engineers weren't responsible for maintaining things like load balancers and things like that, but that's kind of something that falls into your purview in the cloud, right?

Chris: 15:26

Exactly exactly. But if you are preparing for an interview with a tech giant, let's say one of the CSPs, and you will be on the engineering side, where the cloud is built. Go back to my nano talk, where I covered how to do a tech giant interview. That is where we talked about traditional networking. We talked about TCP, IGP and BGP in great details. It's boring details, but that's all you need. And don't be afraid. If you see something there, don't say well, that's too much. No, it's all valid questions. The whole discussion is based on the questions that I've seen, so there are real questions. This discussion will be more focused on the other side of the house, where the cloud is built and offered to the customers as a product.

Kam: 16:13

Awesome. So let's talk about, I guess, kind of the first step in the process, and I think most people out there are probably thinking that, like, the first thing I should do is just go out and start applying for stuff, right, just kind of sending out my resume, doing all that. But given what we've talked about before, you think there's actually a lot of pre-work that should be done before that. Right, some kind of like intel gathering and making sure you're putting in the right foot forward, right, so tell us a little bit about that.

Chris: 16:38

Oh yeah, totally oh yeah. So a little sharing information from backstage. Before we started recording this session, we were talking about the importance of that preparation. So what does it take for me as a candidate to be prepared, even when I'm looking for that job? What does it take? What's the right approach? What are the steps that I need to take?

Chris: 17:03

Many candidates out there just well, I see the, the keywords I'm going to hit, apply and send it, and I hear this a lot that even if you were qualified, or you feel you're qualified for like 30 or 40 percent, just in case, apply. So we I mean together we came up with the idea that that would be nice to have a separate session to just talk about this. What's the right approach? How do I need to approach this? If I have a great resume here, great background and everything else, what's the best way for me to apply for that role?

Chris: 17:35

One of the things that many people miss we're going to cover this, hopefully, in a separate session is let's gather some intel, and by that I mean let me give you an example. Let's say you're applying for a networking position. Could be a cloud network engineer or even traditional network engineering, really doesn't matter, not a huge difference here between the two you apply and well, the point you're missing here is they're asking for some security, maybe a very general term. They're familiar with security appliances. So there are so many different security appliances out there and there are so many different basics of security, foundations of security. There is no way you can prepare for that interview properly. How do I get more information before I go to that? You know, either phone screen or on-site interview. That's what we want to talk about. Go take a look at their career websites. Go look for special keywords. For example, if you're applying for the networking role, see if, at the same time, they're hiring a security architect, if they're hiring a security engineer. In those job descriptions you might actually find better keywords. Wow, this is a Palo Alto customer, this is a Fodinet customer, this is a Cisco ASA customer, this is a Checkpoint customer, or these are the certifications that they care about.

Chris: 18:57

Now you can be a lot more focused in your preparation process. You're not just walking into the whole interview process knowing I need to know security. Well, that's a never-ending discussion. You're going to go there knowing I spent three days on power to firewalls because I know that's going to be part of a discussion. At least I know this is what this guy's using. That's probably the best way to kind of customize your preparation approach. Don't worry about it, it's going to be part of a longer discussion, but for now that's what we mean by you know. Better preparation before you hit apply Right.

Tim: 19:36

Gotcha. So let's get back on topic, then, and let's cover the piece that I guess we want to cover today. Then Just kind of lead us right into it.

Chris: 19:47

There are different ways to approach this whole discussion. The way we decided to structure this session is I came up with I take responsibility here, blame me for that. I came up with three pillars, three big buckets. One of them is let's call them groups Group one, group two and group three. In group one we want to talk about foundations, this well, you want to think about this. It could be interviewer number one 8. Am you start your on-site interview? Interviewer number one's been assigned tasks to ask foundation questions and big part of foundation for any networking job doesn't really matter on-prem cloud carrier as IP and TCP and UDP. So those basic protocols, you gotta know those. We have bullet points on this. I'm going to go go over those. But the whole point is there are different tiers and by tier what I mean is if you're running for a junior position, probably you need to know the basics. Mid-senior I will give you examples. You need to know a little more details. Senior positions no limits. Anything you see anywhere could be related to your job interview and I'll have some examples.

Chris: 21:04

One of the basic questions that many interviewers tend to ask when it comes to the entire protocol discussion is the headers. We start with headers. Let's talk about TCP, udp and IP headers. So first objection here why do I need to memorize all these fields? I've been to interviews as a candidate and the question was name the flags. Well, name the flag and tell me exactly what to do. Oh, okay, I did and then I explained that. But how many people are actually going to memorize those fields? So I've seen those questions. You might want to know those. But the way I personally interview, I give candidates a little bit of like leg room interview. I give candidates a little bit of like leg room here, some a little bit of flexibility, and that is we want to talk about the headers. Name four fields, name five fields or six fields, or compare these headers to the other header, tcp and UDP. Just compare the two headers. Tell me what are the options that look similar? What are the options that difference? Same applies to IPv4 and IPv6 headers. So compare those. What are the options that look similar? What are the options that are different? Same applies to IPv4 and IPv6 headers. So compare those two. But be prepared and in case you get questions on very specific items, do not be surprised. Those items could be anything like the offset scaling. All that fair game could get questions on those. That conversation links.

Chris: 22:21

The next discussion related to TCP and that is a three-way handshake. Believe it or not, it sounds super easy. Many candidates still get that wrong. They could be stressed out, could be a really rough morning. Well, whatever that reason is, this is a basic question you don't want to miss. And then, when you're done with that discussion, the next part is, well, how the package is structured the MTU, mtu discovery. This part is super important. If you have a valid argument about the structure of the header that I don't have to memorize those. That argument doesn't really apply to MTU discussion. Mtu is important. It applies to the cloud. There are many troubleshooting cases that support is working on those and they're MTU related, especially for throughputs. When it comes to MTU, you need to know not just the cloud side but also the operating systems. Sometimes you need to know different operating systems, how the MTU is changing those operating systems, how the TCP stack works. So extremely important points. I pause here for a second. If you want to interject anything, let's cover those and I will go back to the topics.

Tim: 23:32

Yeah. So what I was going to suggest was I've been in those interviews where you feel like the people who came to interview you didn't have relevant questions, so they just kind of went to to google or like, opened up their their tcp, ip volume one illustrated you know, illustrated volume one and went and found some stump the chump questions to kind of come after you with and, uh, those are the the worst interviews, not only because you probably don't remember the thing that they had to go look up themselves, but, uh, because there's no relevant like there's no contextual relevance to what the question? Why did you ask me the question? Like whether it was, do you? I think there was one interview I was in and somebody asked me this question and I don't remember what it was about. It was about I don't remember if it was about ospf or flags or it was something really really, really niche like that and I remember stopping and thinking and just asking, like, is this something you guys run into like all the time? Is this a problem?

Tim: 24:25

in your organization that you're running into and I kind of that kind of short-circuited the whole, the whole thing, but like it's absolutely it's, it's, it's dumb, they're dumb questions. They have to be contextualized, they have to matter to what you want to know exactly.

Chris: 24:38

Oh yeah, one of one of my recommendations to my team members whoever wants to interview candidates is look if there is something like a bug. Let's say, we discover the bug, we spent half a day. The environment was down. After spending half a day and tens of engineering hours, we discovered the bug. We work with the vendor to fix it. That is no interview question. Yeah, there's no way. There's no way that anyone can get that right. So questions like that, I don't know.

Kam: 25:07

I totally disagree with those questions not to derail too much, but I will say there are some. There are some scenarios where I like how it's asked if if it's obviously a stump to chuckle, i'll'll give an example. I I mentioned, uh, or I was in an interview where they were asking me specifically about how, something about how, um, uh, ldp would react to an IP being changed Um, that was used as the source of the session or something like that for for MPLS, label exchange, um, and I remember it was like I don't, I don't know exactly what the thing was, and it was like oh well, you know, we actually had to find this out yesterday because of something we changed and something happened and it was a normal behavior. But I think it can be good just to see how you react to the question. So, like I would say, my advice for when you're in an interview and you get a question that you obviously do not know the answer to, like, don't let it just be like, oh, I don't know, like open it up a little bit.

Chris: 26:07

Let me add something to that. It's a great point. How I would approach it is show them your troubleshooting mindset and troubleshooting approach. This is how I would approach this problem. These are the things I'm going to capture. These are the things I'm going to capture. These are the points I'm going to go to. I'm going to get the vendor on the call and this is the kind of information and log files I will be looking for and altogether, these are like four or five possibilities. This is the best answer. I know you're not going to go. You're not going to say hey, in iOS, whatever, 15.xy that's a bug, especially if someone just just discovered that. So that's probably your best bet. Yeah, absolutely.

Kam: 26:46

But I mean to this point, yeah, I think the, the foundations, are such an important part. We talk about this a lot, how people need to know tcp, udp and ip. Um, so let's, let's kind of get back to that. You've talked about three-way handshake, talked about mtu, maximum transmission, exactly, exactly another important thing the entire congestion control topic.

Chris: 27:05

That's super important. So I can't really think of a single interview where people started talking about ip, tcp and udp and they never covered congestion control. A very smart way to ask that question. And this is how I kind of prep candidates or even talk to the interviewers if you want to agree on some of the questions, to show them a graph, and this graph is really nothing more than throughput whatever's going on. And then there is a drop and then it's picking it back up. So what behavior is shown here? Let me give you three different answers. What behavior is shown here? Let me give you three different answers.

Chris: 27:45

If you were talking to a junior person, what I'm looking for is that's a packet drop and it's a slow start. That's why we're building back up and that's it. It's great for a junior person. Probably mid-senior person is going to give you a little more information that, look, this is, of course, a drop, but we did not hit zero. Something happened. We went down like 50% or 20%. So this is a special behavior of this TCP stack and this is how the SO starts working a little faster than usual, because something else happened behind the scene. Senior candidate.

Chris: 28:17

What I would like to hear hear is give me details on that implementation. That's where I would love if somebody could name that implementation. Is it, is it cube, is it? Uh, whatever, to tahoe behavior is a radio behavior. If somebody gets into that kind of detail. Senior level candidate I'm talking principal here I would love that and even if you start like covering the basics of it, probably that's the end of discussion for me in that section. I'm not going to prob anymore because I know you know your stuff. That's probably the best sign. So, uh, yeah, three different layers and of course, the more the better yeah, I think that's.

Kam: 28:55

I think that's a super important one to know because, if I mean, I think we all kind of remember we may not remember our first, but we probably remember troubleshooting tcp slow start many times in our career because it causes a lot of application issues. So, yeah, that's a that's a very important one and and if you don't know the signs to look for it, then then you don't know, you don't know how to, you know, define the root cause right, exactly, exactly exactly.

Tim: 29:18

One of the driest I mean just bone driest books I've ever read is also probably the one of the best networking books I've ever read, which is a TCP IP illustrated volume. One Like it goes into, oh my God, like eye watering amounts of detail at the Linux level, at the Linux kernel level.

Chris: 29:38

It's right there behind me.

Tim: 29:39

Yeah, I know, and that's my point right, like a lot of junior people looking to prep for interviews at TechGiant like they don't like they know like, oh, I need to study this, but they don't necessarily know, like what is the right resources Exactly exactly, exactly, tim.

Chris: 29:53

We should have talked about this right off the bat. One of the biggest differences between interviewing with a tech giant and, you know, smaller companies is tech giant. You're not going to get configuration questions. I'm not going to ask you hey, what is PortFast? What is like Spanish? Configure this. Or show me how BGP is configured. Or show me how BGP aggregation works.

Chris: 30:20

No, you need to know the theories and those talks and the blog posts and this discussion. All we're trying to do to your point is show the candidates Like highlight the importance of theories. Don't be scared of those books and do your research. Look at the packet captures, try to find out why, why, why? That's how you can nail those interviews. Zero chance. You walk into one of those interviews with a csv, with a cloud provider, and the question is all right, show me how pgp is configured. Nobody cares about it. Most likely even you're not going to be configuring those because for automation in place.

Chris: 30:50

But what we want you to know is well, how bgp operates, how bgp works, what's going on behind the scene. This happened, what are the possibilities? Why? Because every minute of downtime means millions of dollars. Who can find out? Root cause of this. So let's focus on the theories, and probably that's the biggest differentiator between talking to a giant, a major employer. Then you're talking to a smaller company. All they care about for now is, you know, bring up the environments, make sure it operates.

Kam: 31:23

I think that's, I think the importance of theories, is a great point, kim. That's like that's a very important thing, whereas, like you know, there's, there are certain people out there that I hear talk about like, oh, like I read this, it's all theory. There's no implementation. I want, I want the intricate details, but theory is so important because, especially in networking, um, it's rare that someone completely reinvents the wheel, right so it's never happens exactly countless times you can take the theory that you use for one thing and apply it to something else.

Kam: 31:56

You're like I don't know how this technology specifically works, but I know, using common sense based on this other theory, that that it has to operate in one of two ways because there's no other way to do it right. So it's like so important yep.

Chris: 32:07

So uh, well, that's a really great point. Million dollar, I guess. Claim here is. I think we're all ccis in this goal. Uh. So yeah, difference between I talked to many ccis the difference between smart CCI is someone I know is going to pass the test as someone I know this is keyboard people is exactly that Smart CCI. They know the details, they know the theories. When you talk BFT, they can walk you through the mechanics of BFT behind the scenes. When you talk BGP, they can walk you through the entire decision process, entire how the state machine works, all the messaging system, all the attributes. What does it mean? What does this behavior mean? What did the RFC say? But Cisco and Jennifer and somebody else decided to implement different ways. This is what we care about. Everybody can go to the config guides, find a command and put that in. That is why when we took the CCIE test I don't know now, but at least back then it was you had access to documentation. You did.

Chris: 33:09

It's still okay. Back then we had the CD, where we had access to the CD, but I don't know if it's CD or not these days, but that's why because you can find a config For the tech giants.

Chris: 33:19

if you're talking to one of the cloud providers, you got to know the theories. Again, you're not going to get config questions. And that actually brings us to another point on the list TCP and UDP. Compare those two, right. So this question surface level extremely easy. 90% of candidates get that right. And the answer is one of them is reliable, the other one is not. Again, 90 will get that. To get to that point, here's a catch 90 of that 90 gonna stop right there. That's all they know. They know reliable, not reliable, and maybe they could tell you that why there's act and no act process.

Chris: 33:56

How about this question? I'm designing a warehouse and for that warehouse I want to have some kind of fire alarm system, right? This alarm system is connected over some sort of fiber or anything in place. It doesn't really matter To send a fire signal to a back office, to where my operation is located. Your sensors are melting, the building is on fire and you are system designer, network designer. Would you use TCP or UDP for that communication between the two? There's no right or wrong answer. Compare those two, compare and contrast.

Chris: 34:32

What if you implemented TCP? What if you implemented UDP? That will tell me if you know the details of these protocols. That's what I enjoy. Enjoy. That's what I want to hear.

Tim: 34:42

Yeah that's exactly what I was going to suggest. The same. I was like, yeah, great, uh, the next step is I'm designing an app and needs to do this. Tell me, tell me why to use one or the other. That's, that's exactly it, man. That's that's when you really separate the people who read the guide but and just like, memorize the data, the facts, versus the person who understands what that means. Like that's the. That is the person, very true exactly.

Chris: 35:05

Oh yeah, so that's just one example of how important this um you know the protocols are, and right next to that topic you have the key basic troubleshooting uh commands, for example Tracerout and Ping. I interviewed hundreds of candidates and I asked that same question. Majority of candidates know how Ping works, like the whole Echo and Echo Reply business. They know it. Even they could probably open and close, maybe define right policies for firewall. So they know how to permit and make that work. What they do not know is details of trace route. Again, the knowledge is limited to trace route config.

Chris: 35:49

So different trace route implementations, icmp based, udp based, how does it work? And even like some dirty details of it. You're trying to reach a port and by design I pick a port that I know is not going to be open. But what if that port is open? And then how the behavior is going to change, how the trace route is going to react to that. So trace out again is, at least from my perspective, one of those differentiators. When someone can get into details of trace routes, walking through all the steps. Uh, that means a lot. Best way to practice again, as usual, capture packets, don't be scared. Capture packets to see how it works. Use a Windows, use a Linux, run the same command few hops and just inspect the details.

Kam: 36:33

Yeah, I was going to say that there's, I think, people that don't understand how the trace route process works is probably pretty common, Like even just the simple piece about you know the slowly incrementing the TTL value to get the response back right. I feel like that's probably something that doesn't come up too often, and you know what I will say just now, that I have a second to gripe about this, where you talk about how people generally know how ping works. I think one thing that has ruined this for the whole of society is gaming people are like oh, my ping is this, and I'm like dude, that's not what it is, dude

Chris: 37:11

like it drives me nuts I heard it. Yeah, you're right. Um excellent points. Do you remember the?

Tim: 37:18

uh, the old gaming uh terms that they would use. You probably don't, maybe you do. They used to call them LPBs and HPBs. Back in the old days with the modems they called them low ping bastards and high ping bastards. What was?

Kam: 37:34

that YouTube video of the kid explaining the ping response. What was his? Oh my gosh, We'll have to find it.

Tim: 37:39

We've got to find it and we gotta find it put in the notes because I don't remember it's so funny.

Kam: 37:42

Yeah, oh man, if steve mcnutt, if he's listening, he's probably screaming at me because I know he's he loved it. But I'll find it, I'll put it in the notes. It's very funny awesome, cool.

Chris: 37:51

So at this point we can wrap up like group a. Well, did we cover everything? No, but I think we gave. We gave people really good pointers. At least you know what you're talking about. Questions like that, topics like this this is how you want to prepare yourself and then you can apply the same topic to the same basic concept to other topics. But at least you know what you're talking about when we say foundation, when we say details of TCP, udp and IP and troubleshooting commands, that's what we're talking about when we say foundation and we say details of tcp, ugp and ip and troubleshooting commands.

Tim: 38:24

That's what we're looking for yeah, I think to summarize what we're saying is know your shit, but know it beyond the config guide, like that's the. That's the real message to take away is is is know the concept, know the theory, know the concept, know the theory, know the usage, the actual real world point of having a protocol or a process in place.

Chris: 38:45

Exactly. Oh yeah, you also mentioned a couple of books. Those books are important. Capturing packets and inspecting those packet captures is super important. Again, certifications like CCI is super valuable. I'm a CCI myself. I don't want to devalue that, but at the end of the day it's a conflict test. If you're great at configuring stuff and finding things, most likely you're going to pass it.

Tim: 39:07

And fast as shit If you're fast as shit in configuring things too.

Chris: 39:12

Yeah, so that's a possibility. I mean 80% chance you're going to pass it. But we're talking about a little different kind of game here. To win this one you've got to know theories. You're not going to get conflict questions. I'm not going to stop here and say, hey, what was the BGP aggregate command? But we could talk about the atomic aggregate and why it's there. Why is it not? Is it sent, Is it not?

Chris: 39:39

We might talk about those things, but what the command looks like, where nobody really cares. Again, going back to the coding world, it's just like no one's gonna. When you're taking like a coding test, no one's gonna ask questions. Hey, what's the right syntax for the for command or for the while command? People are gonna give you a scenario that you have to design. I don't really care what you want to use. You want to use gw? Care what you want to use. You want to use GW basic or you want to use C sharp, as long as it works, great. But I'm not going to ask syntax questions.

Tim: 40:06

Yeah, that's really good and I think that's definitely the number one, for if you're interviewing at a tech giant, expect that level of question. Don't expect basic configuration questions. I think that's the big takeaway.

Chris: 40:18

Exactly exactly configuration questions. I think that's a big takeaway exactly, exactly and real quick. Here it is not. I want to emphasize this point. This is important. It's not our personal opinion. This is based on the feedback we got from people. It's based on the feedback I got after I gave that last call a stock, that peter reached out and said look, we use this video, we use the points that we summarized and super helpful. We were actually asked those questions and before the interview I had no idea it was important. I knew bgp inside out but I realized, wow, there is this thing here that I never heard of and that exact same thing showed up.

Kam: 40:53

So again, go beyond configuration and keep in mind theories are super important yeah, I think probably, if you're someone that's like just looking at roles and maybe you're like a little bit discouraged, like look, I don't have time to learn all this stuff now, like the role is up now, I think this is probably a sign that if you can't, really if you don't have some of the foundations locked in, maybe you're not ready. Right, if you're gonna do it, you might as well do it right and make sure. If you're in the ballpark and you have a lot of the topics down, you think, and there's just smaller gaps to fill, then I'd say, go ahead and, you know, put your app in, but you know you don't want to, you know you don't want to first impressions or everything you know. That's very true, very true, very true.

Chris: 41:34

Let me just a little spoiler here. I know we're going to do it separate, no talk on this, but a little spoiler. When the recruiter reaches out and they want to schedule a time to do a phone screen, especially technical phone screen, I know you're excited. I know you have not got a call. In what weeks? Months? Do not say tomorrow. This is crazy. You need time to prep. You need time to go through their job description. You need time to look at, hopefully, your, your notes and, if not, those books, and be 100% prepared. Someone might pick up the phone and say name those TCP files or name the field that in the header does X, y or Z, right on the phone as part of the phone screen right after the greeting. So be prepared for that kind of conversation.

Tim: 42:20

Well, also, you need time to network too, man. This industry is so what's the word I'm looking for Like the family is very tight, right, everybody knows everybody in this industry. They just don't know that they know everybody in this industry. I say this all the time, and so another part of that not just doing the research on the company, but do some research on your network as well. It's very likely that you might know somebody that can give you the download and give you some, some info, some tips, some suggestions for that specific company excellent points yeah yeah you're rarely more than two, two connections away from somebody in this that's right.

Tim: 42:52

It's very true the longer in it, the more true it is that's right.

Chris: 42:56

Exactly that's why no one should post anything crazy on LinkedIn. Not everyone is abiding by that this day and age. But yeah, I totally agree, people should do that. All right, cool. So we're done with group A or group one. This is our first bucket we can just side and cover the second buckets.

Kam: 43:35

Yeah, we'll absolutely do that. I think we're just about out of time today, but let's definitely plan to do that, all right, great, well, I think this has been a great introduction to the overall pat, or else, you know, especially with the tech giant, it's not going to take you very far, right? So be on the lookout. We're going to have probably a second and third piece to this piece, to this series here, so we're really excited to bring Cam back to do that and we'll have that out in the coming weeks. And I guess, cam, do you have any closing thoughts before we depart?

Chris: 44:11

No, it was a great discussion. Thank you so much for your time and looking forward to everyone's feedback Awesome.

Kam: 44:13

Yeah, if there's anything that you specifically want to hear in part two or three, definitely give us feedback in the comments. Dms. Go to Tim's house, you know, tell him, tell him smoke signals.

Kam: 44:22

Please smoke signals. All right, thanks a lot, guys. This has been the cables to clouds podcast and we will see you next week. Thank you so much. Bye, bye, hi everyone, it's Chris and this has been the cables to clouds podcast. Thanks for tuning in today. If you enjoyed our show, please subscribe to us in your favorite podcatcher, as well as subscribe and turn on notifications for our YouTube channel to be notified of all our new episodes. Follow us on socials at Cables to Clouds. You can also visit our website for all of the show notes at CablesToCloudscom. Thanks again for listening and see you next time.