July 9, 2025 • 34 mins
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
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Chris (00:00):
Hey everybody, it is Chris from over here at Cables
to Clouds.
Thanks for joining us this weekfor our episode.
Unfortunately, tim is on somecurrent overseas travel to Japan
, so unfortunately you just gotme this week.
But luckily, today we are goingto be releasing part three of
our series with Cam McGuigan onhow to interview with a tech
(00:24):
giant.
So if you kind of go back, um,look through the show notes if
you haven't heard the first twoepisodes, they're really good on
going over kind of the kind ofthe foundation to going through
one of these interviews with thetech giant.
Um, we get into kind of the bitsand pieces about you know what
kind of routing protocols andthings like that you should be
learning, what kind of skillsets you should be focusing on
things like that, and in thisepisode we get a little bit
(00:47):
further into it about additionalconcepts 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.
So with that out of the way,let's hop into the episode.
Okay, yeah, so good progress.
(01:19):
So you've kind of, you know,made it through this second
interview where you're talking alot about common networking
constructs, and there's a lot ofcloud nuance sprinkled in there
as well.
Let's maybe take it a stepfurther and let's start talking
about where you're probablygonna get some questions around
the specific networking ornetworking adjacent services
that the CSPs offer as well,right, cause there's a lot of
(01:41):
those that are kind of brand newterritory to a lot of
traditional network engineers,right?
So let's kind of go over someof those and the importance is
there.
Kam (01:50):
Excellent.
Exactly, it's quite a fewservices.
So let's say, now you're donewith the second interview,
second technical interview.
And for the third interview, Iwould like to know do you know
knowledge when it comes to ourservices?
This is a very broad topic andit varies from one cloud
provider to another.
Some cloud providers haveextensive SaaS services how to
(02:14):
get to SaaS.
Some do not have any SaaS andsome of them support services
that do not exist in the otherone, for example, native CDN,
non-native CDN.
All that to, I guess, find thekind of common grounds.
I want to talk about some verycommon services, most common
services that these days networkengineers or cloud network
(02:37):
engineers find themselvesconfiguring or providing design
suggestions even sometimes ourcase answering to RFP questions
is the whole area of securityhow to secure your environment
in terms of firewalls.
That's one thing.
The other thing is how is mywhole name resolution process
(02:58):
going to work in a cloud?
So the DNS topic and the thirdone is load balancer.
Traditionally, if you go backto your data centers, I would
say pretty much all the threeareas were kind of gray area.
Some system app people wantedto own them.
Sometimes they didn't want to.
We would own part of that In acloud.
(03:21):
We still have the sameconversation, but a little
clearer.
At least, when we work withcustomers, we try to make it
very clear that let's take alook at firewalls for a second
Extremely important, extremelyimportant solution.
It's really hard to find even asingle customer these days
doesn't want to use any firewall.
But whose responsibility isthat?
(03:42):
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 maybekind of joint responsibility?
I'm personally not a huge fanof joint responsibility when it
comes to configuring a devicelike this, where we kind of
split responsibilities is, thereis a clear line and, by the way
(04:07):
, this is how I approach this.
There might be many other ways,I'm sure there are, but this is
how I would approach this andhow I shape my interview process
is as long as you can routeyour traffic to the appliance,
to my firewall, to that securitysolution, the networking person
is done.
Your job is complete.
(04:28):
There is someone else whounderstands the bigger security
posture, who understands how myoverall security should look
like.
That person works with me tocreate my security policies.
How I want to treat differenttypes of traffic.
What are major threats?
How I want to react.
(04:48):
Am I going to just permit andlog?
I want to deny types of traffic.
What are major threats?
How I want to react.
Am I going to just permit andlog?
I want to deny Ingress, ingress.
These are not kind of decisionsthat I personally want a
network engineer to make.
If you find yourself in asituation where you're making
not just routing decision butalso overall security posture, I
would say probably that's likea little too broad sort of job
(05:09):
description.
But again, from my perspective,the standard way you look at
the architecture, there are twogeneral ways, and that also
applies to the interview process.
One of them is you create avirtual machine, vm shape,
instance, different terminologyand you load your third-party
(05:31):
firewall.
It could be a Palo Altofirewall, it could be a Cisco
ASA, it could be a Fodderfirewall, it doesn't really
matter.
You bring up that firewall onthat instance and what happens
there is.
That solution would almostsupport, I would say, 98%
probably of all the featuresthat you had on your traditional
firewall, pretty much identicalto your firewall.
(05:54):
This is, of course, this alsoneeds your licenses and all
those things that somebody elseneeds to worry about it, or you
need to make sure it haslicenses.
That's how people would bringup firewalls up until probably
four years ago, five years ago.
There is another way and that'sthe kind of recent solution CSB
(06:15):
is now offering their ownfirewalls and in most cases,
deploying those firewalls couldsimplify your architecture with
a little fine print that thosefirewalls might not support
every single feature that youwould get out of your full-blown
firewall running on a VM.
(06:36):
So you need to find out corefeatures you need on your
security appliance and whetherthe service, the CSP, supports
that feature or not.
Once again, as a networkengineer, I do not want you to
make that call and when it comesto the interview process, this
is pretty much all you need toknow about what's going on on
(06:57):
that box.
But how you route traffic tothose solutions very much
depends on your CSP.
So you need to go back todocumentation of that CSP.
We have extensive documentation.
I know AWS does, I know AWSdoes, I know Azure does, and
they clearly explain how tocapture traffic, how to kick it
over the firewall, how toinstall the firewall in path or
(07:20):
off path and how to process.
How about a spoke model orsomething else?
How to scale it?
These scenarios probably arethe most complex architectures
that could come up when you'retalking to someone for a network
engineering role in the cloudhow to architect and how to
deploy appliances orCSP-specific firewalls.
(07:43):
So that's a very importanttopic.
Tim (07:46):
Yeah, I think the routing thing is such a big deal,
especially with the CSP nativefirewalls.
I mean, unless you're like, forexample, I know in AWS you have
like the firewall endpointwhich is basically a Gavi load
balancer with a different hat onat the end of the day.
So that's just a matter oforchestrating a route table to
point at the load balancer.
Kam (08:04):
But yeah, in general it's a big complicated routing thing.
Tim (08:06):
but yeah, in general it's a big, complicated routing thing
probably that's the mostcomplicated topic, I think to
your point.
Chris (08:14):
If you're interviewing specifically with someone that
is at this scale, I highly,highly doubt they're going to
have individuals sharing thesame hat of networking and
firewall management.
I would certainly hope so ifyou're doing both Not a tech
giant.
Tim (08:31):
I take pity on you for sure .
I worked enterprise where I didfirewall, network, collab, data
center.
You love collab.
I did every single.
I did all of them, includingcollab.
But that was an enterprise, man, an enterprise.
All bets are off.
Right, we're talking about atech giant A tech giant?
Probably not.
That's not going to happen toyou at a tech giant.
Kam (08:51):
When was it 1999?
Tim (08:54):
No, not that long ago.
This was back in 2015-ish, soyeah, it wasn't too bad.
Kam (08:59):
Oh yeah, yeah, we all have one of those jobs.
But these days, I guess theamount of knowledge is so vast
it is you can't really expect asingle person to track all your
security threats, all thevulnerabilities and everything
else.
Again, we're talking aboutoverall security posture.
I'm not talking about a singlepolicy.
How to configure that that'sprobably the least important
(09:21):
thing how that single policy isgoing to work with your overall
security posture.
Track that plus the entirenetwork.
This is a little big for evenone team, so it has to be a
little separation ofresponsibilities here.
So that's the topic of security.
Again, two flavors.
Make sure you know which CSPyou're talking about.
(09:44):
And good news is they allpublish their architectures.
And again, another good news isunlike publish their
architectures.
And again, another good news isunlike I gotta be very careful
here unlike traditionalnetworking, you cannot get super
innovative and creative.
So there are not a milliondifferent architectures that you
could create around that,around the service in on that
(10:07):
CSP solution.
You could create around thatCSP solution.
You could make somemodifications, you could kind of
update it, customize it alittle, but it's not like you
can just blow it up and thenrebuild the architecture the way
you want it, completelydifferent from what they
recommended.
So extent of that architectureis limited to what they
recommend plus minus, probably10%, 20%, but again that's most
(10:31):
likely the most difficultquestion that could come up.
But again, there'sdocumentation out there and
there's not going to be a lot ofmodifications to their
architectures.
Chris (10:41):
Yeah, totally yeah.
There's usually two to threeways to get something done and
you're not going to see muchvariance there without doing a
lot of work over the top, whichis just going to add a lot of
overhead.
Uh, complexity for you, but Ithink I think you call it a
really good point in that one ofthe major things about working
(11:01):
in cloud is going to have to bearound third-party integrations,
um, because you're not like youknow some people, some people
do like look, I'm only using theCSP native services and I'm
never using anything outside ofthat, um, but there that comes
at a, at a, at a pretty penny,right, Um.
So you know, sometimes you youdo want to stick with, um, some
(11:22):
other, uh, alternatives,alternatives, you know, maybe
you want to use Fortinet or Palofor your inspection, just
because the price point is somuch better, right?
So I think that is super key inintegrating those third-party
solutions, and what are thedrawbacks and what are the
advantages?
Kam (11:39):
Oh yeah, the management plane how you want to manage
those you know, monitoring, howyou want to receive logs and
process, so it all matters.
That's just a very interestingtopic.
The next kind of service is DNSand name resolution.
Once again, there are twopossibilities here Traditional
(12:01):
DNS knowledge around DNS, dnstheories.
You need to know that.
So if you're talking to someonelike me, I would love to go
back.
I want to go back to the dayswe had host file, we had lm host
, we had wind server how do youbind?
here we go.
We had, we had bind, and thenwe upgraded the bind.
Some bind would work withactive directory, some of them
wouldn't, and then withoutintegration, active directory,
(12:23):
and then, and then, and then weget to a point where now we have
the csp and and now in the CSPyou have your name resolution
process.
It's a very straightforwardthing.
If you want to stay within thecloud, most customers they want
to have name resolution betweenthe cloud and what they have
on-prem, and that introduces youto the world of hybrid
(12:44):
architectures.
Same recommendation that Chrisand I were talking about again
applies in this case Every CSP.
They have their own set ofarchitectures, clearly published
and through some recommendedsolutions and best practices.
There's not going to be amillion variations of those.
You could make some changes toit again, plus minus, maybe 10%,
(13:06):
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 isright there.
So if you're preparing forthose interviews, get a hold of
the documentation, whiteboard itmany times I would say at least
five times, and you will seehow, on one side, you're going
(13:30):
to grab that query, kick it overto other side, resolution and
back, and it remains the sameacross.
But you need to know those.
You know maybe two or threearchitectures per CSP.
Tim (13:43):
I got to give a shameless plug here.
Steve McNutt did a really greatchapter in our AWS advanced
networking guide that we justreleased on DNS on-prem hybrid
in-cloud and all of the endpointresolvers.
He went way beyond what wasnecessary.
(14:03):
Yeah, it was great.
Kam (14:05):
Absolutely, absolutely.
So.
That's another interestingagain topic and cool thing is
you have the architectures.
You need to spend timemastering those architectures
and that is pretty much itaround DNS.
There is one little topic herethat's not trying to scare
anyone, but I got to tell youthis.
(14:26):
It's DNSSEC, and DNSSEC is oneof the topics it's.
It's kind of a little morecomplicated than traditional dns
.
You gotta know the theories,you know how it works and be
prepared to spend some timethere.
I would say maybe five, sixhours.
Read a few times, try it.
Two key, two key questions whyand how?
(14:49):
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 overallsecurity and that kind of
details.
It's an interesting topic.
That kind of details.
It's an interesting topic Nowthat you're running out for your
(15:11):
book.
In my book also, the DNA sexsection took a lot of time
because I would write it, Iwould ask somebody else to read
it.
I was like what are you talkingabout?
This is simple and again, Iwould simplify and simplify and
simplify.
So five, six iterations of thesame chapter until my third
(15:32):
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 youby asking just one DNS question,
that would be probably DNSSECand 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 theANS on the same topic.
Oh yeah, on the same topic.
So this is actually kind offunny, right, it's like
everybody on this podcast rightnow has written a book on the
advanced networking specialtycertification.
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 likethis, so my intention was I'm
going to have set of questions,I'm going to have a set of
scenarios that people are goingto look at this and I'm going to
have 200 mini scenarios and myintention was to have small
(16:31):
scenarios maybe 200 of them andthat's how I'm going to explain
topic of cloud.
And then I kind of changed mymind.
I'm going to do something likethis I'm going to have one big
scenario and that scenario like40 pages, and then 50 pages of
description and how things aredone.
I actually did that and thenlater I decided to make it free,
(16:54):
available to everyone.
If you look for that PDF file,you can find it.
It's a CCDE-style cloudengineering scenario that I
published three years ago, fouryears ago, and I never no, I
never sold it and it's free outthere.
Take a look and it walks youthrough the chaotic organization
that people are having problemstrying to do migration to cloud
(17:17):
and they fail.
And then the last version of itwas, you know what, not this,
not the other one.
I'm going to do this.
I'm going to have questionslike a set of questions, three
or four sets of questions, but Ilike bullet points.
I understand bullet points alot better than I understand any
kind of text.
I grab my text, whatever Iwanted, to write all the
(17:40):
paragraphs and I turn them intobullet points.
So some people like it, somepeople don't like it, but I
personally, when I see things ina very organized way, with all
the invitation, I get the topicbetter.
So that's how I arrived thereand 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 hadcompletely forgotten about that
because when they first asked usto do it, we I was looking
around.
Chris (18:14):
I was like.
I was like I'm sure someoneelse 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 Iwas fine with.
I was like oh cool.
I was like I, and then I waslike I kind of want to get it,
but kind of don't want to get itbecause then it's going to like
mess me up when I'm writingmine or something.
I didn't want to have it dothat.
So now that I'm done with thatbook, you've now reminded me.
Now I want to go back and checkit out.
We need to get into the shownotes.
Kam (18:36):
So long story short, the DNS section of it took a lot of
time because the topic by itselfwas pretty, I guess, dry and to
some users difficult tounderstand.
But I chewed on it many times.
Four or five iterations laterit's now easier to understand.
Anyways, if you've read it forthe first time on anyone's
website and you feel it isdifficult, it is.
Chris (18:59):
It's a little more difficult than other than the
traditional dns, but four orfive hours later, if you spend
time on it, it's really nothingunusual yeah, I think, um, just
to kind of echo home on thatpoint you call out specifically,
you know obviously DNSSEC is ahuge topic and you know the
concept of DNS architecture isabout public versus private.
(19:22):
I don't know if this is exactlywhat you even mean by that.
But one thing that was alsokind of huge for me was
understanding kind of thenetwork architecture for how you
speak with DNS or how youresolve things Like with local
resolvers and like that can bedistributed in certain manners,
like I don't.
I you know obviously.
I know AWS, probably the bestin that scenario, but I know
(19:45):
Azure and probably OCI have thesimilar constructs right and
it's there's nuance toeverything.
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 thetheories, you need to know DNS
in general, name resolution ingeneral and it reminds me of
that Nanook talk.
You type in an address in youraddress bar, hit enter, walk me
through the steps.
And a good part of thatdiscussion and of course the
(20:18):
interviewer's answer was whathappens 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 gettingspun up on the CSP, like most of
them have some kind of randomlyassigned like DNS name that you
know other services can referto, or like you know that are
just become part of the processyou 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 resolvenames.
So we actually have a blog poston that one, but there are those
(21:09):
scenarios.
We actually have a blog post onthat one, but there are these
scenarios.
But again, for a job interview,unless you're interviewing for
a very senior level role, Iguess the interviewer should not
go there.
You need to know how DNS works,you need to know those hybrid
architectures and I expect youto know DNSSEC maybe a little
(21:29):
more, but that's pretty much theextent of you know safe
knowledge to approach um jobinterview for this role for sure
, oh speaking of multi-cloud.
(21:56):
I mean that's obviously a hugeconnecting to clouds and you had
AWS, I had OCI, somebody elsein Azure wanted to connect this
too.
Somebody else had GCP and wetalked about IPsec.
We talked about, you know,equinix, megaport, different
ways to connect those cloudproviders to each other and give
(22:18):
you like a fabric.
Today, I guess, starting maybeabout two years ago, year and a
half ago, two years ago CSPs arekind of embracing each other's
solutions.
I've got to be very carefulhere.
One example is Oracle databases.
Now can be, physical databases,like we're talking about Excel
(22:40):
machines in somebody else's datacenter, in this case AWS, azure
and GCP data centers, so youcan consume Oracle databases
with all the good stuff thatthey had from within your
Microsoft data center.
So that's the new kind ofnotion of multi-cloud.
When we talk about multi-cloudit's not just connecting the two
(23:04):
clouds.
So there are at least from myperspective, there are three
flavors out there.
One of them is you connect thetwo cloud providers using a
third-party solution Equinix,megaport, someone else, or your
own IPsec tunnel.
The other one we had dedicatedconnections to other cloud
providers.
We had one to Azure.
We had one to GCP not justphysically one, that as a
(23:26):
solution and then this new onethat is placing databases in
somebody else's data center andphysical machines in somebody
else's data center.
So these are three kind ofinteresting architectures.
Why would I notice when I go toa job interview, you could
easily impress me as aninterviewer as someone who
(23:47):
studies look at the news, knowswhat's going on.
Someone who studies, look atthe news knows what's going on.
You go a little beyond.
You know Cam's or Tim's orChris's book.
You go a little beyond what'sin that configuration file,
what's in the console so youknow the latest that's happening
out there.
You could absolutely impress meif you could share.
Well, for example, in thisregion it is available.
(24:09):
Not available.
Going to be up in this regionin maybe six or 12 months.
That tells me.
You know that kind of stuff.
But multi-cloud is a quicklychanging space.
I expect to hear a lot more inthe next 12 months, but this is
unbelievable.
This is absolutely unbelievable.
(24:31):
Three years ago this didn'tmake 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 onOracle's kind of multi-cloud
partnerships for a while and Ithink our kind of thought about
it was like, oh, do we loseChris?
Oh, brilliant, I'll just keep.
And our thought about it wasbasically like, hey, what a
(24:59):
smart thing for Oracle to do.
Having been a little later tothe game as a provider, it makes
sense for Oracle to reach outand provide essentially the
Oracle experience or the Oracledatabases, or whatever and just
partner with other CSPs.
Kam (25:18):
Absolutely, absolutely.
Oh yeah, if you're alreadyusing somebody else's IES
services.
You built a lot ofinfrastructure somewhere else,
but you love your Oracledatabase performance on-prem.
Now you could get it fromwithin that CSP.
I just talk to them.
They provide an offer and youcan use our hardware placed in
(25:40):
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'retalking about the concept of
specifically interviewing at atech giant, this kind of differs
.
You know whether or not you'retalking about a CSP, a cloud
service provider, or you'retalking about just maybe a very
large enterprise type deal.
Right, because I think in someof those scenarios like the on
(26:05):
the on the enterprise side, youknow, if you want to kind of I
mean, this is my, this is myopinion but I think if you want
to kind of do some researchahead of time to determine
whether or not you know they're,they are a multi-cloud
environment Um, if it doesn'tsay it in the job posting, some
telltale signs that what we'veseen that usually lead to
something like that is, um, bigacquisitions.
(26:26):
Uh, acquisitions usually meanthey're acquiring another
company that already is in onecloud.
It may not be different or maynot be the same one that they're
using today.
And you know kind of anotherone that I see a lot is you know
if a company has done a lot ofmaybe posts or you know kind of
(26:46):
general initiatives to kind ofdecentrify is that a word?
Decentrify, like mitigate risk,is where I'm trying to take
this right, so kind ofdistribute risk and avoid, you
know, lock in with one specificenvironment 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 ofmitigating 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, Becausesometimes you know certain
clouds bring things quicker tomarket than others and that fits
, you know, kind of the businesscase.
So I think those are kind ofsome important things to focus
on, at least on the enterpriseside, from what I can tell.
I don't know if, Cam, if youfeel that's the same on the CSP
(27:41):
side or where you guys typicallystraddle that line.
Kam (27:45):
Totally.
Oh yeah, we kind of talkedabout it as well.
Oh yeah, we kind of talkedabout it as well.
So this multi-cloud conceptsort of started with that
locking concern that I don'twant to be using just one cloud.
I want to have DR in adifferent cloud.
Well, one level up.
And now, well, maybe the othercloud offers some services that
(28:06):
my original CSP doesn't.
How about I use some of theirservices but consume some other
services from the other CSP?
And it is an absolutely growingtrend.
Like I said, it's very importantthat you spend some time not on
that particular job descriptionyou're applying for, but also
(28:27):
their other job descriptionsthey posted on their career
website.
It's so important I just can'temphasize enough.
Go to that website, look forkeywords like cloud.
They might have one CISO jobposted.
They might have one applicationperson posted job posted.
(28:47):
They might have some securityor anything else related to the
cloud posted In those jobdescriptions.
I'm sure you can start fishingfor keywords.
Sure you can start fishing forkeywords if you know this is
well your role.
You're being interviewed foraws or oci or azure, and in
(29:08):
other job description you comeacross.
Well, there's gcv here.
So there's a great chance thatthis customer is a multi-cloud
customer.
Or you're going through yourcloud network engineering job
description.
You don't see anything on flowbalancers, for example.
But you go to the other onewhen you look for keyword cloud
(29:31):
and you realize, wow, these guysare also hiring application
people or application or cloudapplication specialists, and in
that job description there's alot on the load balancers.
Tim (29:42):
Right.
Kam (29:43):
Although they might not directly ask questions on the
load balancer, ask you questionson the load balancer, but who
knows, there might be questionskind of related and those
scenarios are pretty common.
Just to give you one example,there is a.
There is actually one of myfavorite scenarios.
Let me just spoil it here.
(30:03):
Um, you have a little balancer.
You're sending traffic to someback-end servers and all of a
sudden you realize, wow, one ofmy back-ends getting a lot of
traffic unusually high.
You do your due diligence, allinspection Turns out there's
some kind of NAT going on at thesource, whoever that source is,
and your load balancer is justpinning all the traffic to one
(30:26):
particular backend.
You're able to explain thatchain?
It is a network engineeringtask.
I don't expect my applicationperson to know how NAT works,
how my inner traffic works, howit's routed and why he's getting
all the traffic into one device.
From their perspective, thismight be something as simple as
(30:48):
well.
Look at this source anddestination.
It's generating a lot oftraffic not knowing there are
15,000 machines behind thatsource 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 tuplesthat can cause that kind of flow
pitting to happen, that's verymuch a network engineer type of
task.
Yeah, I would not have expectedan application person to
understand the tuples.
Kam (31:17):
That's one example.
If you don't see load balancerin your job description, but it
is in somebody else's jobdescription, it could be related
to you as well.
Chris (31:26):
All right.
So, man, this has been quite ajourney.
So we've gotten through prettymuch a three-part series, all
kind of talking about theprocess of an interview that you
will go through for,specifically, a cloud network
engineer position at a techgiant.
So I think this has been great.
So, you know, we've gonethrough kind of some really
(31:46):
foundational elements as far astechnology and even venturing
into things like talking aboutthe research that you need to do
as an individual about thecompany that you're applying for
.
So I think this has really beeninsightful and you know, if
anyone has any questions,definitely reach out.
But, cam, I want to give youthe opportunity to give us any
closing thoughts that you mayhave about the entire process.
Kam (32:08):
Really, not much left.
We've talked a lot and covereda lot of ground.
Usual thoughts Number one dospend a lot of time not on your
job description, on other jobdescriptions of the company.
Find out what they are hiring,what they hired recently.
Take a look at some people'sprofiles and what they're doing.
(32:29):
What are their recent projects?
What are they excited about?
What are the keywords?
That's another important thingand in these talks, what we did
was we gave you a lot ofpointers, we gave you a lot of
keywords, but we did not get achance to explain everything.
I mean, we're not supposed to.
We did not create this podcastto teach you basics of BGP or
(32:52):
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 yourselfon those things.
Pretty much every single pointthat we brought up today and
previous episodes.
(33:12):
Those are important questions.
These are questions that we'veseen before and if you grab one
of those keywords, you'restarting a chapter.
You come across something thatyou don't know.
Go on, just keep going andeducate yourself.
Those are important topics.
So we tried, really tried ourbest to cover the most important
(33:32):
topics and it was just 100%meets like very, very lean.
So good luck, and there's goingto be future episodes, some
other topics, but I think forcloud network engineering, we
covered what we wanted.
I'm happy with the outcome.
Thank you so much, tim.
Thanks, chris, for spendingtime and recording these
(33:54):
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 weedson the technology, but I think
that people should be able toleave this with a strong
syllabus to follow to make surethat they're prepared.
So, if anyone has any questions, feedback concerns, our inbox
is always open, so reach out tous and yeah, we'll see you next
week.
Kam (34:21):
Wonderful Thank you.
Hey everybody, it is Chris from over here at Cables
to Clouds.
Thanks for joining us this weekfor our episode.
Unfortunately, tim is on somecurrent overseas travel to Japan
, so unfortunately you just gotme this week.
But luckily, today we are goingto be releasing part three of
our series with Cam McGuigan onhow to interview with a tech
(00:24):
giant.
So if you kind of go back, um,look through the show notes if
you haven't heard the first twoepisodes, they're really good on
going over kind of the kind ofthe foundation to going through
one of these interviews with thetech giant.
Um, we get into kind of the bitsand pieces about you know what
kind of routing protocols andthings like that you should be
learning, what kind of skillsets you should be focusing on
things like that, and in thisepisode we get a little bit
(00:47):
further into it about additionalconcepts 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.
So with that out of the way,let's hop into the episode.
Okay, yeah, so good progress.
(01:19):
So you've kind of, you know,made it through this second
interview where you're talking alot about common networking
constructs, and there's a lot ofcloud nuance sprinkled in there
as well.
Let's maybe take it a stepfurther and let's start talking
about where you're probablygonna get some questions around
the specific networking ornetworking adjacent services
that the CSPs offer as well,right, cause there's a lot of
(01:41):
those that are kind of brand newterritory to a lot of
traditional network engineers,right?
So let's kind of go over someof those and the importance is
there.
Kam (01:50):
Excellent.
Exactly, it's quite a fewservices.
So let's say, now you're donewith the second interview,
second technical interview.
And for the third interview, Iwould like to know do you know
knowledge when it comes to ourservices?
This is a very broad topic andit varies from one cloud
provider to another.
Some cloud providers haveextensive SaaS services how to
(02:14):
get to SaaS.
Some do not have any SaaS andsome of them support services
that do not exist in the otherone, for example, native CDN,
non-native CDN.
All that to, I guess, find thekind of common grounds.
I want to talk about some verycommon services, most common
services that these days networkengineers or cloud network
(02:37):
engineers find themselvesconfiguring or providing design
suggestions even sometimes ourcase answering to RFP questions
is the whole area of securityhow to secure your environment
in terms of firewalls.
That's one thing.
The other thing is how is mywhole name resolution process
(02:58):
going to work in a cloud?
So the DNS topic and the thirdone is load balancer.
Traditionally, if you go backto your data centers, I would
say pretty much all the threeareas were kind of gray area.
Some system app people wantedto own them.
Sometimes they didn't want to.
We would own part of that In acloud.
(03:21):
We still have the sameconversation, but a little
clearer.
At least, when we work withcustomers, we try to make it
very clear that let's take alook at firewalls for a second
Extremely important, extremelyimportant solution.
It's really hard to find even asingle customer these days
doesn't want to use any firewall.
But whose responsibility isthat?
(03:42):
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 maybekind of joint responsibility?
I'm personally not a huge fanof joint responsibility when it
comes to configuring a devicelike this, where we kind of
split responsibilities is, thereis a clear line and, by the way
(04:07):
, this is how I approach this.
There might be many other ways,I'm sure there are, but this is
how I would approach this andhow I shape my interview process
is as long as you can routeyour traffic to the appliance,
to my firewall, to that securitysolution, the networking person
is done.
Your job is complete.
(04:28):
There is someone else whounderstands the bigger security
posture, who understands how myoverall security should look
like.
That person works with me tocreate my security policies.
How I want to treat differenttypes of traffic.
What are major threats?
How I want to react.
(04:48):
Am I going to just permit andlog?
I want to deny types of traffic.
What are major threats?
How I want to react.
Am I going to just permit andlog?
I want to deny Ingress, ingress.
These are not kind of decisionsthat I personally want a
network engineer to make.
If you find yourself in asituation where you're making
not just routing decision butalso overall security posture, I
would say probably that's likea little too broad sort of job
(05:09):
description.
But again, from my perspective,the standard way you look at
the architecture, there are twogeneral ways, and that also
applies to the interview process.
One of them is you create avirtual machine, vm shape,
instance, different terminologyand you load your third-party
(05:31):
firewall.
It could be a Palo Altofirewall, it could be a Cisco
ASA, it could be a Fodderfirewall, it doesn't really
matter.
You bring up that firewall onthat instance and what happens
there is.
That solution would almostsupport, I would say, 98%
probably of all the featuresthat you had on your traditional
firewall, pretty much identicalto your firewall.
(05:54):
This is, of course, this alsoneeds your licenses and all
those things that somebody elseneeds to worry about it, or you
need to make sure it haslicenses.
That's how people would bringup firewalls up until probably
four years ago, five years ago.
There is another way and that'sthe kind of recent solution CSB
(06:15):
is now offering their ownfirewalls and in most cases,
deploying those firewalls couldsimplify your architecture with
a little fine print that thosefirewalls might not support
every single feature that youwould get out of your full-blown
firewall running on a VM.
(06:36):
So you need to find out corefeatures you need on your
security appliance and whetherthe service, the CSP, supports
that feature or not.
Once again, as a networkengineer, I do not want you to
make that call and when it comesto the interview process, this
is pretty much all you need toknow about what's going on on
(06:57):
that box.
But how you route traffic tothose solutions very much
depends on your CSP.
So you need to go back todocumentation of that CSP.
We have extensive documentation.
I know AWS does, I know AWSdoes, I know Azure does, and
they clearly explain how tocapture traffic, how to kick it
over the firewall, how toinstall the firewall in path or
(07:20):
off path and how to process.
How about a spoke model orsomething else?
How to scale it?
These scenarios probably arethe most complex architectures
that could come up when you'retalking to someone for a network
engineering role in the cloudhow to architect and how to
deploy appliances orCSP-specific firewalls.
(07:43):
So that's a very importanttopic.
Tim (07:46):
Yeah, I think the routing thing is such a big deal,
especially with the CSP nativefirewalls.
I mean, unless you're like, forexample, I know in AWS you have
like the firewall endpointwhich is basically a Gavi load
balancer with a different hat onat the end of the day.
So that's just a matter oforchestrating a route table to
point at the load balancer.
Kam (08:04):
But yeah, in general it's a big complicated routing thing.
Tim (08:06):
but yeah, in general it's a big, complicated routing thing
probably that's the mostcomplicated topic, I think to
your point.
Chris (08:14):
If you're interviewing specifically with someone that
is at this scale, I highly,highly doubt they're going to
have individuals sharing thesame hat of networking and
firewall management.
I would certainly hope so ifyou're doing both Not a tech
giant.
Tim (08:31):
I take pity on you for sure .
I worked enterprise where I didfirewall, network, collab, data
center.
You love collab.
I did every single.
I did all of them, includingcollab.
But that was an enterprise, man, an enterprise.
All bets are off.
Right, we're talking about atech giant A tech giant?
Probably not.
That's not going to happen toyou at a tech giant.
Kam (08:51):
When was it 1999?
Tim (08:54):
No, not that long ago.
This was back in 2015-ish, soyeah, it wasn't too bad.
Kam (08:59):
Oh yeah, yeah, we all have one of those jobs.
But these days, I guess theamount of knowledge is so vast
it is you can't really expect asingle person to track all your
security threats, all thevulnerabilities and everything
else.
Again, we're talking aboutoverall security posture.
I'm not talking about a singlepolicy.
How to configure that that'sprobably the least important
(09:21):
thing how that single policy isgoing to work with your overall
security posture.
Track that plus the entirenetwork.
This is a little big for evenone team, so it has to be a
little separation ofresponsibilities here.
So that's the topic of security.
Again, two flavors.
Make sure you know which CSPyou're talking about.
(09:44):
And good news is they allpublish their architectures.
And again, another good news isunlike publish their
architectures.
And again, another good news isunlike I gotta be very careful
here unlike traditionalnetworking, you cannot get super
innovative and creative.
So there are not a milliondifferent architectures that you
could create around that,around the service in on that
(10:07):
CSP solution.
You could create around thatCSP solution.
You could make somemodifications, you could kind of
update it, customize it alittle, but it's not like you
can just blow it up and thenrebuild the architecture the way
you want it, completelydifferent from what they
recommended.
So extent of that architectureis limited to what they
recommend plus minus, probably10%, 20%, but again that's most
(10:31):
likely the most difficultquestion that could come up.
But again, there'sdocumentation out there and
there's not going to be a lot ofmodifications to their
architectures.
Chris (10:41):
Yeah, totally yeah.
There's usually two to threeways to get something done and
you're not going to see muchvariance there without doing a
lot of work over the top, whichis just going to add a lot of
overhead.
Uh, complexity for you, but Ithink I think you call it a
really good point in that one ofthe major things about working
(11:01):
in cloud is going to have to bearound third-party integrations,
um, because you're not like youknow some people, some people
do like look, I'm only using theCSP native services and I'm
never using anything outside ofthat, um, but there that comes
at a, at a, at a pretty penny,right, Um.
So you know, sometimes you youdo want to stick with, um, some
(11:22):
other, uh, alternatives,alternatives, you know, maybe
you want to use Fortinet or Palofor your inspection, just
because the price point is somuch better, right?
So I think that is super key inintegrating those third-party
solutions, and what are thedrawbacks and what are the
advantages?
Kam (11:39):
Oh yeah, the management plane how you want to manage
those you know, monitoring, howyou want to receive logs and
process, so it all matters.
That's just a very interestingtopic.
The next kind of service is DNSand name resolution.
Once again, there are twopossibilities here Traditional
(12:01):
DNS knowledge around DNS, dnstheories.
You need to know that.
So if you're talking to someonelike me, I would love to go
back.
I want to go back to the dayswe had host file, we had lm host
, we had wind server how do youbind?
here we go.
We had, we had bind, and thenwe upgraded the bind.
Some bind would work withactive directory, some of them
wouldn't, and then withoutintegration, active directory,
(12:23):
and then, and then, and then weget to a point where now we have
the csp and and now in the CSPyou have your name resolution
process.
It's a very straightforwardthing.
If you want to stay within thecloud, most customers they want
to have name resolution betweenthe cloud and what they have
on-prem, and that introduces youto the world of hybrid
(12:44):
architectures.
Same recommendation that Chrisand I were talking about again
applies in this case Every CSP.
They have their own set ofarchitectures, clearly published
and through some recommendedsolutions and best practices.
There's not going to be amillion variations of those.
You could make some changes toit again, plus minus, maybe 10%,
(13:06):
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 isright there.
So if you're preparing forthose interviews, get a hold of
the documentation, whiteboard itmany times I would say at least
five times, and you will seehow, on one side, you're going
(13:30):
to grab that query, kick it overto other side, resolution and
back, and it remains the sameacross.
But you need to know those.
You know maybe two or threearchitectures per CSP.
Tim (13:43):
I got to give a shameless plug here.
Steve McNutt did a really greatchapter in our AWS advanced
networking guide that we justreleased on DNS on-prem hybrid
in-cloud and all of the endpointresolvers.
He went way beyond what wasnecessary.
(14:03):
Yeah, it was great.
Kam (14:05):
Absolutely, absolutely.
So.
That's another interestingagain topic and cool thing is
you have the architectures.
You need to spend timemastering those architectures
and that is pretty much itaround DNS.
There is one little topic herethat's not trying to scare
anyone, but I got to tell youthis.
(14:26):
It's DNSSEC, and DNSSEC is oneof the topics it's.
It's kind of a little morecomplicated than traditional dns
.
You gotta know the theories,you know how it works and be
prepared to spend some timethere.
I would say maybe five, sixhours.
Read a few times, try it.
Two key, two key questions whyand how?
(14:49):
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 overallsecurity and that kind of
details.
It's an interesting topic.
That kind of details.
It's an interesting topic Nowthat you're running out for your
(15:11):
book.
In my book also, the DNA sexsection took a lot of time
because I would write it, Iwould ask somebody else to read
it.
I was like what are you talkingabout?
This is simple and again, Iwould simplify and simplify and
simplify.
So five, six iterations of thesame chapter until my third
(15:32):
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 youby asking just one DNS question,
that would be probably DNSSECand 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 theANS on the same topic.
Oh yeah, on the same topic.
So this is actually kind offunny, right, it's like
everybody on this podcast rightnow has written a book on the
advanced networking specialtycertification.
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 likethis, so my intention was I'm
going to have set of questions,I'm going to have a set of
scenarios that people are goingto look at this and I'm going to
have 200 mini scenarios and myintention was to have small
(16:31):
scenarios maybe 200 of them andthat's how I'm going to explain
topic of cloud.
And then I kind of changed mymind.
I'm going to do something likethis I'm going to have one big
scenario and that scenario like40 pages, and then 50 pages of
description and how things aredone.
I actually did that and thenlater I decided to make it free,
(16:54):
available to everyone.
If you look for that PDF file,you can find it.
It's a CCDE-style cloudengineering scenario that I
published three years ago, fouryears ago, and I never no, I
never sold it and it's free outthere.
Take a look and it walks youthrough the chaotic organization
that people are having problemstrying to do migration to cloud
(17:17):
and they fail.
And then the last version of itwas, you know what, not this,
not the other one.
I'm going to do this.
I'm going to have questionslike a set of questions, three
or four sets of questions, but Ilike bullet points.
I understand bullet points alot better than I understand any
kind of text.
I grab my text, whatever Iwanted, to write all the
(17:40):
paragraphs and I turn them intobullet points.
So some people like it, somepeople don't like it, but I
personally, when I see things ina very organized way, with all
the invitation, I get the topicbetter.
So that's how I arrived thereand 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 hadcompletely forgotten about that
because when they first asked usto do it, we I was looking
around.
Chris (18:14):
I was like.
I was like I'm sure someoneelse 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 Iwas fine with.
I was like oh cool.
I was like I, and then I waslike I kind of want to get it,
but kind of don't want to get itbecause then it's going to like
mess me up when I'm writingmine or something.
I didn't want to have it dothat.
So now that I'm done with thatbook, you've now reminded me.
Now I want to go back and checkit out.
We need to get into the shownotes.
Kam (18:36):
So long story short, the DNS section of it took a lot of
time because the topic by itselfwas pretty, I guess, dry and to
some users difficult tounderstand.
But I chewed on it many times.
Four or five iterations laterit's now easier to understand.
Anyways, if you've read it forthe first time on anyone's
website and you feel it isdifficult, it is.
Chris (18:59):
It's a little more difficult than other than the
traditional dns, but four orfive hours later, if you spend
time on it, it's really nothingunusual yeah, I think, um, just
to kind of echo home on thatpoint you call out specifically,
you know obviously DNSSEC is ahuge topic and you know the
concept of DNS architecture isabout public versus private.
(19:22):
I don't know if this is exactlywhat you even mean by that.
But one thing that was alsokind of huge for me was
understanding kind of thenetwork architecture for how you
speak with DNS or how youresolve things Like with local
resolvers and like that can bedistributed in certain manners,
like I don't.
I you know obviously.
I know AWS, probably the bestin that scenario, but I know
(19:45):
Azure and probably OCI have thesimilar constructs right and
it's there's nuance toeverything.
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 thetheories, you need to know DNS
in general, name resolution ingeneral and it reminds me of
that Nanook talk.
You type in an address in youraddress bar, hit enter, walk me
through the steps.
And a good part of thatdiscussion and of course the
(20:18):
interviewer's answer was whathappens 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 gettingspun up on the CSP, like most of
them have some kind of randomlyassigned like DNS name that you
know other services can referto, or like you know that are
just become part of the processyou 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 resolvenames.
So we actually have a blog poston that one, but there are those
(21:09):
scenarios.
We actually have a blog post onthat one, but there are these
scenarios.
But again, for a job interview,unless you're interviewing for
a very senior level role, Iguess the interviewer should not
go there.
You need to know how DNS works,you need to know those hybrid
architectures and I expect youto know DNSSEC maybe a little
(21:29):
more, but that's pretty much theextent of you know safe
knowledge to approach um jobinterview for this role for sure
, oh speaking of multi-cloud.
(21:56):
I mean that's obviously a hugeconnecting to clouds and you had
AWS, I had OCI, somebody elsein Azure wanted to connect this
too.
Somebody else had GCP and wetalked about IPsec.
We talked about, you know,equinix, megaport, different
ways to connect those cloudproviders to each other and give
(22:18):
you like a fabric.
Today, I guess, starting maybeabout two years ago, year and a
half ago, two years ago CSPs arekind of embracing each other's
solutions.
I've got to be very carefulhere.
One example is Oracle databases.
Now can be, physical databases,like we're talking about Excel
(22:40):
machines in somebody else's datacenter, in this case AWS, azure
and GCP data centers, so youcan consume Oracle databases
with all the good stuff thatthey had from within your
Microsoft data center.
So that's the new kind ofnotion of multi-cloud.
When we talk about multi-cloudit's not just connecting the two
(23:04):
clouds.
So there are at least from myperspective, there are three
flavors out there.
One of them is you connect thetwo cloud providers using a
third-party solution Equinix,megaport, someone else, or your
own IPsec tunnel.
The other one we had dedicatedconnections to other cloud
providers.
We had one to Azure.
We had one to GCP not justphysically one, that as a
(23:26):
solution and then this new onethat is placing databases in
somebody else's data center andphysical machines in somebody
else's data center.
So these are three kind ofinteresting architectures.
Why would I notice when I go toa job interview, you could
easily impress me as aninterviewer as someone who
(23:47):
studies look at the news, knowswhat's going on.
Someone who studies, look atthe news knows what's going on.
You go a little beyond.
You know Cam's or Tim's orChris's book.
You go a little beyond what'sin that configuration file,
what's in the console so youknow the latest that's happening
out there.
You could absolutely impress meif you could share.
Well, for example, in thisregion it is available.
(24:09):
Not available.
Going to be up in this regionin maybe six or 12 months.
That tells me.
You know that kind of stuff.
But multi-cloud is a quicklychanging space.
I expect to hear a lot more inthe next 12 months, but this is
unbelievable.
This is absolutely unbelievable.
(24:31):
Three years ago this didn'tmake 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 onOracle's kind of multi-cloud
partnerships for a while and Ithink our kind of thought about
it was like, oh, do we loseChris?
Oh, brilliant, I'll just keep.
And our thought about it wasbasically like, hey, what a
(24:59):
smart thing for Oracle to do.
Having been a little later tothe game as a provider, it makes
sense for Oracle to reach outand provide essentially the
Oracle experience or the Oracledatabases, or whatever and just
partner with other CSPs.
Kam (25:18):
Absolutely, absolutely.
Oh yeah, if you're alreadyusing somebody else's IES
services.
You built a lot ofinfrastructure somewhere else,
but you love your Oracledatabase performance on-prem.
Now you could get it fromwithin that CSP.
I just talk to them.
They provide an offer and youcan use our hardware placed in
(25:40):
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'retalking about the concept of
specifically interviewing at atech giant, this kind of differs
.
You know whether or not you'retalking about a CSP, a cloud
service provider, or you'retalking about just maybe a very
large enterprise type deal.
Right, because I think in someof those scenarios like the on
(26:05):
the on the enterprise side, youknow, if you want to kind of I
mean, this is my, this is myopinion but I think if you want
to kind of do some researchahead of time to determine
whether or not you know they're,they are a multi-cloud
environment Um, if it doesn'tsay it in the job posting, some
telltale signs that what we'veseen that usually lead to
something like that is, um, bigacquisitions.
(26:26):
Uh, acquisitions usually meanthey're acquiring another
company that already is in onecloud.
It may not be different or maynot be the same one that they're
using today.
And you know kind of anotherone that I see a lot is you know
if a company has done a lot ofmaybe posts or you know kind of
(26:46):
general initiatives to kind ofdecentrify is that a word?
Decentrify, like mitigate risk,is where I'm trying to take
this right, so kind ofdistribute risk and avoid, you
know, lock in with one specificenvironment 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 ofmitigating 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, Becausesometimes you know certain
clouds bring things quicker tomarket than others and that fits
, you know, kind of the businesscase.
So I think those are kind ofsome important things to focus
on, at least on the enterpriseside, from what I can tell.
I don't know if, Cam, if youfeel that's the same on the CSP
(27:41):
side or where you guys typicallystraddle that line.
Kam (27:45):
Totally.
Oh yeah, we kind of talkedabout it as well.
Oh yeah, we kind of talkedabout it as well.
So this multi-cloud conceptsort of started with that
locking concern that I don'twant to be using just one cloud.
I want to have DR in adifferent cloud.
Well, one level up.
And now, well, maybe the othercloud offers some services that
(28:06):
my original CSP doesn't.
How about I use some of theirservices but consume some other
services from the other CSP?
And it is an absolutely growingtrend.
Like I said, it's very importantthat you spend some time not on
that particular job descriptionyou're applying for, but also
(28:27):
their other job descriptionsthey posted on their career
website.
It's so important I just can'temphasize enough.
Go to that website, look forkeywords like cloud.
They might have one CISO jobposted.
They might have one applicationperson posted job posted.
(28:47):
They might have some securityor anything else related to the
cloud posted In those jobdescriptions.
I'm sure you can start fishingfor keywords.
Sure you can start fishing forkeywords if you know this is
well your role.
You're being interviewed foraws or oci or azure, and in
(29:08):
other job description you comeacross.
Well, there's gcv here.
So there's a great chance thatthis customer is a multi-cloud
customer.
Or you're going through yourcloud network engineering job
description.
You don't see anything on flowbalancers, for example.
But you go to the other onewhen you look for keyword cloud
(29:31):
and you realize, wow, these guysare also hiring application
people or application or cloudapplication specialists, and in
that job description there's alot on the load balancers.
Tim (29:42):
Right.
Kam (29:43):
Although they might not directly ask questions on the
load balancer, ask you questionson the load balancer, but who
knows, there might be questionskind of related and those
scenarios are pretty common.
Just to give you one example,there is a.
There is actually one of myfavorite scenarios.
Let me just spoil it here.
(30:03):
Um, you have a little balancer.
You're sending traffic to someback-end servers and all of a
sudden you realize, wow, one ofmy back-ends getting a lot of
traffic unusually high.
You do your due diligence, allinspection Turns out there's
some kind of NAT going on at thesource, whoever that source is,
and your load balancer is justpinning all the traffic to one
(30:26):
particular backend.
You're able to explain thatchain?
It is a network engineeringtask.
I don't expect my applicationperson to know how NAT works,
how my inner traffic works, howit's routed and why he's getting
all the traffic into one device.
From their perspective, thismight be something as simple as
(30:48):
well.
Look at this source anddestination.
It's generating a lot oftraffic not knowing there are
15,000 machines behind thatsource 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 tuplesthat can cause that kind of flow
pitting to happen, that's verymuch a network engineer type of
task.
Yeah, I would not have expectedan application person to
understand the tuples.
Kam (31:17):
That's one example.
If you don't see load balancerin your job description, but it
is in somebody else's jobdescription, it could be related
to you as well.
Chris (31:26):
All right.
So, man, this has been quite ajourney.
So we've gotten through prettymuch a three-part series, all
kind of talking about theprocess of an interview that you
will go through for,specifically, a cloud network
engineer position at a techgiant.
So I think this has been great.
So, you know, we've gonethrough kind of some really
(31:46):
foundational elements as far astechnology and even venturing
into things like talking aboutthe research that you need to do
as an individual about thecompany that you're applying for
.
So I think this has really beeninsightful and you know, if
anyone has any questions,definitely reach out.
But, cam, I want to give youthe opportunity to give us any
closing thoughts that you mayhave about the entire process.
Kam (32:08):
Really, not much left.
We've talked a lot and covereda lot of ground.
Usual thoughts Number one dospend a lot of time not on your
job description, on other jobdescriptions of the company.
Find out what they are hiring,what they hired recently.
Take a look at some people'sprofiles and what they're doing.
(32:29):
What are their recent projects?
What are they excited about?
What are the keywords?
That's another important thingand in these talks, what we did
was we gave you a lot ofpointers, we gave you a lot of
keywords, but we did not get achance to explain everything.
I mean, we're not supposed to.
We did not create this podcastto teach you basics of BGP or
(32:52):
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 yourselfon those things.
Pretty much every single pointthat we brought up today and
previous episodes.
(33:12):
Those are important questions.
These are questions that we'veseen before and if you grab one
of those keywords, you'restarting a chapter.
You come across something thatyou don't know.
Go on, just keep going andeducate yourself.
Those are important topics.
So we tried, really tried ourbest to cover the most important
(33:32):
topics and it was just 100%meets like very, very lean.
So good luck, and there's goingto be future episodes, some
other topics, but I think forcloud network engineering, we
covered what we wanted.
I'm happy with the outcome.
Thank you so much, tim.
Thanks, chris, for spendingtime and recording these
(33:54):
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 weedson the technology, but I think
that people should be able toleave this with a strong
syllabus to follow to make surethat they're prepared.
So, if anyone has any questions, feedback concerns, our inbox
is always open, so reach out tous and yeah, we'll see you next
week.
Kam (34:21):
Wonderful Thank you.
Popular Podcasts
Crime Junkie
Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you won’t hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, you’ve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by audiochuck Media Company.
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.