Re: questions asked during network engineer interview

[Mark Tinka]

On 24/Jul/20 18:41, William Herrin wrote:

> How you parse it depends on your intention when quoting my interview
> story with a response about exhibiting curiosity. It was either full
> agreement about the value of curiousity or a pointed retort about the
> difference between curiosity and irresponsibility.

I'll give the NANOG dwellers (ourselves included) the benefit of the
doubt for having kicked irresponsibility to the curb. So I think we can
agree on the former.

Mark.

Re: questions asked during network engineer interview

[William Herrin]

On Fri, Jul 24, 2020 at 12:44 AM Mark Tinka  wrote:
> On 24/Jul/20 09:32, William Herrin wrote:
> > Choosing not to mash one's fingers with a hammer is not an absence of
> > curiosity about carpentry. It's merely an understanding that doing
> > carpentry well involves -not- mashing one's fingers with a hammer.
>
> You mean like not poking your finger into the wall socket, or in the
> fire, unless you're 2?
>
> I'm not sure how to parse your comment. But in case you are wondering, I
> am talking about network engineering, which is not common sense.

Hi Mark,

How you parse it depends on your intention when quoting my interview
story with a response about exhibiting curiosity. It was either full
agreement about the value of curiousity or a pointed retort about the
difference between curiosity and irresponsibility.

Regards,
Bill

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: questions asked during network engineer interview

[Greg Skinner via NANOG]

Comments inline.

> On Jul 14, 2020, at 3:35 PM, Andrey Khomyakov  
> wrote:
> 
> I was once asked at a FANG interview how I would affect incoming traffic 
> using BGP. I listed the usual offenders like AS path and med. He kept asking 
> how else, to which after pondering I said that I cant think of other ways 
> right now. He was insisting I find one, so I theorized on using more specific 
> prefix even though that?s technically not a BGP method.

Using the Origin comes to mind, but according to RFC 4271, that shouldn’t be 
done.  IMO, it’s not fair to ask candidates to do things that the generally 
accepted reference material strongly cautions against. 

> I think that was when he decided I failed, and I decided that he wanted me to 
> name a creative method he himself used at his megascaler. Considering I never 
> had to even think about solving problems at their scale I think that was just 
> dumb to insist I come up with it. 
> I?ll never know what that magical method is since he didn?t actually give me 
> the answer I didn?t know ?\_(?)_/? 

I would not have been happy if an interviewer didn’t tell me the answer [s]he 
expected.  At the very least, I would have asked if I could refer to RFC 4271 
during the interview.

> The interview in general seemed to be more about technical nerd knobs of 
> random technologies and less about how I think about problems. 
> 
> My take is that nerd knobs can be taught and/or looked up. How a person 
> thinks and dissects the problems at hand can hardly be changed easily.

I agree that how people think about problems is something that should be more 
important on interviews than specific answers.  That said, in this particular 
case, the interviewer could have been looking for a response such as “the 
tie-breaking procedures in BGP route selection are not limited to what is 
documented in RFC 4271.”  There are people who have implemented such 
procedures, some of whom may be on this list.  (I have seen NANOG listed as a 
interest of theirs on their LinkedIn profiles.)  Perhaps, if they are reading 
this thread, they would comment on what type of response they are looking for, 
if they ask such questions.

> The question about ?what happens when you enter google.com into your browser? 
> is probably my favorite and I ask it to candidates every time. That and ?how 
> can you confirm a remote system is listening on a given TCP port?. Idk what 
> it is that confuses people, but close to zero people answered ?telnet or 
> netcat to that port? and most of them went down the ?I ssh into the system? 
> or ?I look in the firewall? or ?I netstat?.

I’ve never asked anyone that question, but it’s been asked of me a few times.  
Before saying anything else, I ask what specifically is the interviewer looking 
for — how google.com  is resolved by DNS? how the HTTP 
request (if HTTP is the method) is handled? how packets move from the machine 
the user is typing on through the Internet?  There are “entire universes” of 
discussion that could be had in response to this question.  I’ve also been told 
that it is highly recommended (at some companies) to ask questions in response 
to questions that are open-ended, because the companies don’t want to hear 
“stackoverflow responses” that could have been memorized.

> Another one is ?what is the summary prefix for 10.0.0.0/24 and 10.0.1.0/24?. 
> So.many.minds.blown! Some ask for pen and paper. Others just start doing 
> binary conversions out loud

I don’t necessarily think this is a bad thing.  The candidates may be being 
careful because they don’t want to make a mistake on an “easy” question, 
fearing that getting it wrong could drop them from consideration.  They also 
might regularly use tools that do this sort of thing, and don’t regularly have 
to answer that type of question without these tools, in much the same way that 
people (generally) use calculators instead of pen and paper for “simple” 
arithmetic.

> Turns out there are as many bad candidates as there are interviewers. I 
> consider myself a bad interviewer so I try to shy away from interviewing 
> candidates if I can. And based on this email chains so far it seems like 
> there is not an agreed upon good interview method.

Perhaps there will never be an agreed upon good interview method.  I wish this 
was communicated to the mainstream press and politicians who have been led to 
believe that companies can’t find the right people because of insufficient 
education.  This may be true, but it is not guaranteed to be true.

—gregbo

Re: questions asked during network engineer interview

[Mark Tinka]

On 24/Jul/20 09:59, Peter Kristolaitis wrote:
 
>
> I would suggest that companies who follow FAANG-type development
> models actually value both expertise and curiosity, and also throw in
> the ability and willingness to rapidly iterate.  Certainly one can
> search Google for solutions to nearly any problem, but it takes
> expertise to take the bits you find and structure them in a way that
> makes sense for your particular problem -- both to solve the immediate
> problem and to make addition of future features or bug fixes easier.

And I agree with this. You need some reasonable level of base expertise
in order to get the gig first.

What I mean with "curiousity" being much more important nowadays is that
the skills you got the gig with may not necessarily apply in their
entirety as you rapidly iterate. So what your expertise gets you, at
that point, is the fastest path toward the result of your curiousity in
figuring out how to adjust with the changing landscape. When you get
that result, you add to your expertise, further reinforcing your
curiousity; and so the wheel goes.

What I am not in support of is expertise getting hired, and assuming it
doesn't need to be curious anymore because you hired it for what it was
good at. That is how you find yourself in the same place, 10 years
later, reminiscing about how great Multicast was. Except that with how
ubiquitous the Internet is now, obsolescence has a much shorter
gestation window than 10 years.

Mark.

Re: questions asked during network engineer interview

[Peter Kristolaitis]

On 2020-07-24 3:06 a.m., Mark Tinka wrote:


On 24/Jul/20 00:26, William Herrin wrote:


Many moons ago, I interviewed at Google. During one of the afternoon
sessions the interviewer and I spent about half an hour spitballing
approaches for system monitoring problem at scale. I no longer
remember the details. With a little over 15 minutes remaining he
handed me a marker and said, "Okay, now write code for that on the
whiteboard." For an abstract problem without foundation that I had
never considered prior to that discussion. I said, "I really don't
think I can do a credible job of that in the time we have." He says,
"Well it's okay to use pseudocode. Don't you want to try?" I think
you're missing the point dude. It's still an abstract problem and
after half an hour's discussion I might be ready to draw boxes and
arrows. I'm certainly not ready to reduce it to code.

I said, "No," and needless to say I didn't get an offer. And I'm okay
with that. I really didn't fancy making a career of competing to be
the first to write poorly considered software.

The booby prize for failing the interview was a Google coffee mug. I
still have it in storage somewhere.

Where the industrial revolution praised expertise, the digital
revolution rewards curiousity.

I prefer to have staff that are burdened with being curious, rather than
staff who think they don't. After all, all the information is already
out there. Having experience is just as important as being diligent to
obtain it.

Mark.


I would suggest that companies who follow FAANG-type development models 
actually value both expertise and curiosity, and also throw in the 
ability and willingness to rapidly iterate.  Certainly one can search 
Google for solutions to nearly any problem, but it takes expertise to 
take the bits you find and structure them in a way that makes sense for 
your particular problem -- both to solve the immediate problem and to 
make addition of future features or bug fixes easier.


I suspect the question posed to Mr. Herrin was intended to probe not 
just the expertise factor, but the iteration factor as well -- firstly, 
can you, with only partial requirements (or minimally-viable-product 
requirements), structure your code in such a way that it covers the 
currently-known requirements and reasonable design assumptions given the 
nature of the system (how does the control loop work?  are we collecting 
data by polling or pushing?  what layer is responsible for aggregation?  
how do we define a new monitoring check?  what are the interface points 
with external systems?  how are alert thresholds set?)?   Secondly, 
after you're done that exercise, if we throw a (reasonable) new 
requirement at you, is your code well-structured enough that the change 
doesn't necessitate a complete rewrite?


I've never been to an interview where I received a 400-page design 
document that is blessed by all 18 major stakeholders before being asked 
to write code.    It's almost always either small, well-defined problems 
(which are often related to your understanding of algorithmic 
complexity) or an iterative design process as above.  In the latter 
case, the point isn't to write perfect and flawless code for version 1, 
it's to see how you write version 0.1alpha and then how you think about 
getting to version 5.


And, realistically, we're talking about an interview here.  There are 
time constraints, and no one (interviewer or interviewee) should expect 
a production-grade system as the output of some whiteboarding exercises.

Re: questions asked during network engineer interview

[Mark Tinka]

On 24/Jul/20 09:53, Wayne Bouchard wrote:

>
> Well, I take the point of his comment to be not being curious to the
> point of inadvertantly doing damage to something that you were better
> off leaving alone until you found someone who could clue you in to the
> particulars. There are plenty of network engineers out there who, in
> going about their job--and especially when trying out new
> features, figuratively mashed their figures with that hammer.
> Curiosity, yes, but also self-discipline.

How you mold your engineers, and the kind of management you put them
under, will determine how useful they are to you, and themselves. Often,
having the potential to give you a competitive advantage, within your
community.

No one came out the womb knowing how to build Internet networks. You've
hired well. Now train and mold well.

Your staff can be curious without breaking the network. That is the
responsibility of you, their leader.

Mark.

Re: questions asked during network engineer interview

[Wayne Bouchard]

On Fri, Jul 24, 2020 at 09:44:36AM +0200, Mark Tinka wrote:
> 
> 
> On 24/Jul/20 09:32, William Herrin wrote:
> 
> > Choosing not to mash one's fingers with a hammer is not an absence of
> > curiosity about carpentry. It's merely an understanding that doing
> > carpentry well involves -not- mashing one's fingers with a hammer.
> 
> You mean like not poking your finger into the wall socket, or in the
> fire, unless you're 2?
> 
> I'm not sure how to parse your comment. But in case you are wondering, I
> am talking about network engineering, which is not common sense.
> 
> Mark.

Well, I take the point of his comment to be not being curious to the
point of inadvertantly doing damage to something that you were better
off leaving alone until you found someone who could clue you in to the
particulars. There are plenty of network engineers out there who, in
going about their job--and especially when trying out new
features, figuratively mashed their figures with that hammer.
Curiosity, yes, but also self-discipline.

-Wayne

---
Wayne Bouchard
w...@typo.org
Network Dude
http://www.typo.org/~web/

Re: questions asked during network engineer interview

[Mark Tinka]

On 24/Jul/20 09:32, William Herrin wrote:

> Choosing not to mash one's fingers with a hammer is not an absence of
> curiosity about carpentry. It's merely an understanding that doing
> carpentry well involves -not- mashing one's fingers with a hammer.

You mean like not poking your finger into the wall socket, or in the
fire, unless you're 2?

I'm not sure how to parse your comment. But in case you are wondering, I
am talking about network engineering, which is not common sense.

Mark.

Re: questions asked during network engineer interview

[William Herrin]

On Fri, Jul 24, 2020 at 12:08 AM Mark Tinka  wrote:
> I prefer to have staff that are burdened with being curious, rather than
> staff who think they don't. After all, all the information is already
> out there. Having experience is just as important as being diligent to
> obtain it.

Choosing not to mash one's fingers with a hammer is not an absence of
curiosity about carpentry. It's merely an understanding that doing
carpentry well involves -not- mashing one's fingers with a hammer.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: questions asked during network engineer interview

[Mark Tinka]

On 24/Jul/20 00:26, William Herrin wrote:

> Many moons ago, I interviewed at Google. During one of the afternoon
> sessions the interviewer and I spent about half an hour spitballing
> approaches for system monitoring problem at scale. I no longer
> remember the details. With a little over 15 minutes remaining he
> handed me a marker and said, "Okay, now write code for that on the
> whiteboard." For an abstract problem without foundation that I had
> never considered prior to that discussion. I said, "I really don't
> think I can do a credible job of that in the time we have." He says,
> "Well it's okay to use pseudocode. Don't you want to try?" I think
> you're missing the point dude. It's still an abstract problem and
> after half an hour's discussion I might be ready to draw boxes and
> arrows. I'm certainly not ready to reduce it to code.
>
> I said, "No," and needless to say I didn't get an offer. And I'm okay
> with that. I really didn't fancy making a career of competing to be
> the first to write poorly considered software.
>
> The booby prize for failing the interview was a Google coffee mug. I
> still have it in storage somewhere.

Where the industrial revolution praised expertise, the digital
revolution rewards curiousity.

I prefer to have staff that are burdened with being curious, rather than
staff who think they don't. After all, all the information is already
out there. Having experience is just as important as being diligent to
obtain it.

Mark.

Re: questions asked during network engineer interview

[Valdis Klētnieks]

On Thu, 23 Jul 2020 10:03:15 +0100, adamv0...@netconsultings.com said:

> Hopefully well end up in a world where all checks one can do to figure out
> why iBGP session is down along with suggested corrective actions will be coded
> in some network self-healing workflow.

/me places bets this concept re-surfaces as SDNv3. :)


pgp6JQjIlh7Sz.pgp
Description: PGP signature

Re: questions asked during network engineer interview

[Michael Thomas]

On 7/23/20 3:26 PM, William Herrin wrote:

On Thu, Jul 23, 2020 at 6:33 AM Michael Douglas
 wrote:

One time I got asked in an interview how to estimate the number of manholes in 
a city.  I replied that I would google 'pretentious interview questions' for a 
problem solving methodology.

Many moons ago, I interviewed at Google. During one of the afternoon
sessions the interviewer and I spent about half an hour spitballing
approaches for system monitoring problem at scale. I no longer
remember the details. With a little over 15 minutes remaining he
handed me a marker and said, "Okay, now write code for that on the
whiteboard." For an abstract problem without foundation that I had
never considered prior to that discussion. I said, "I really don't
think I can do a credible job of that in the time we have." He says,
"Well it's okay to use pseudocode. Don't you want to try?" I think
you're missing the point dude. It's still an abstract problem and
after half an hour's discussion I might be ready to draw boxes and
arrows. I'm certainly not ready to reduce it to code.


I would have probably asked whether he'd fire me if I started writing 
code after 15 minutes of handwaving in real life.


Mike

Re: questions asked during network engineer interview

[William Herrin]

On Thu, Jul 23, 2020 at 6:33 AM Michael Douglas
 wrote:
> One time I got asked in an interview how to estimate the number of manholes 
> in a city.  I replied that I would google 'pretentious interview questions' 
> for a problem solving methodology.

Many moons ago, I interviewed at Google. During one of the afternoon
sessions the interviewer and I spent about half an hour spitballing
approaches for system monitoring problem at scale. I no longer
remember the details. With a little over 15 minutes remaining he
handed me a marker and said, "Okay, now write code for that on the
whiteboard." For an abstract problem without foundation that I had
never considered prior to that discussion. I said, "I really don't
think I can do a credible job of that in the time we have." He says,
"Well it's okay to use pseudocode. Don't you want to try?" I think
you're missing the point dude. It's still an abstract problem and
after half an hour's discussion I might be ready to draw boxes and
arrows. I'm certainly not ready to reduce it to code.

I said, "No," and needless to say I didn't get an offer. And I'm okay
with that. I really didn't fancy making a career of competing to be
the first to write poorly considered software.

The booby prize for failing the interview was a Google coffee mug. I
still have it in storage somewhere.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: questions asked during network engineer interview

[Mel Beckman]

I was going to ask “So where did you eventually get a job after that 
interview?” :)

 -mel beckman

On Jul 23, 2020, at 2:22 PM, Sabri Berisha  wrote:


- On Jul 23, 2020, at 6:31 AM, Michael Douglas  
wrote:
One time I got asked in an interview how to estimate the number of manholes in 
a city.  I replied that I would google 'pretentious interview questions' for a 
problem solving methodology.
Did you get hired? :)

Thanks,

Sabri

Re: questions asked during network engineer interview

[Sabri Berisha]

- On Jul 23, 2020, at 6:31 AM, Michael Douglas  
wrote: 

> One time I got asked in an interview how to estimate the number of manholes 
> in a
> city. I replied that I would google 'pretentious interview questions' for a
> problem solving methodology.

Did you get hired? :) 

Thanks, 

Sabri 

Re: questions asked during network engineer interview

[Mehmet Akcin]

I am trying to have a 2nd session tomorrow to go over all discussions here.

who would like to join me live on this session and talk about interview
questions, experience for network engineers? please let me know. I plan to
schedule for 11am pacific tomorrow

On Thu, Jul 23, 2020 at 6:32 AM Michael Douglas 
wrote:

> One time I got asked in an interview how to estimate the number of
> manholes in a city.  I replied that I would google 'pretentious interview
> questions' for a problem solving methodology.
>
> On Thu, Jul 23, 2020 at 5:06 AM  wrote:
>
>> > Mark Tinka
>> > Sent: Thursday, July 23, 2020 5:04 AM
>> >
>> > On 23/Jul/20 01:04, Brandon Martin wrote:
>> >
>> > >
>> > > Of course, there's also plenty of folks out there without them or any
>> > > certs at all that are just as useful in practice.  Getting those
>> > > particular certifications does, however, seem to be a useful path to
>> > > learning things that are actually of use in the "real world".  I look
>> > > at such certificates similar to how I'd look at a 2- or 4-year degree
>> > > in a related IT field and just a somewhat different, and perhaps more
>> > > approachable for the self-coached or differently-learning, path.
>> >
>> > We live in a time where I am concerned about the engineers we
>> > are creating, where point & click seems to trump basic understanding +
>> CLI
>> > knowledge. My concern is when it all goes to hell at 3AM, do the next
>> > generation of network engineers have the base fundamentals to understand
>> > why iBGP isn't coming up, even though you can "ping" and IGP adjacencies
>> > are up and stable?
>> >
>> Hopefully well end up in a world where all checks one can do to figure
>> out why iBGP session is down along with suggested corrective actions will
>> be coded in some network self-healing workflow.
>> But to answer your question, probably no, cause current industry is
>> systematically converting network engineers into coders.
>>
>> adam
>>
>>
>>

Re: questions asked during network engineer interview

[Michael Douglas]

One time I got asked in an interview how to estimate the number of manholes
in a city.  I replied that I would google 'pretentious interview questions'
for a problem solving methodology.

On Thu, Jul 23, 2020 at 5:06 AM  wrote:

> > Mark Tinka
> > Sent: Thursday, July 23, 2020 5:04 AM
> >
> > On 23/Jul/20 01:04, Brandon Martin wrote:
> >
> > >
> > > Of course, there's also plenty of folks out there without them or any
> > > certs at all that are just as useful in practice.  Getting those
> > > particular certifications does, however, seem to be a useful path to
> > > learning things that are actually of use in the "real world".  I look
> > > at such certificates similar to how I'd look at a 2- or 4-year degree
> > > in a related IT field and just a somewhat different, and perhaps more
> > > approachable for the self-coached or differently-learning, path.
> >
> > We live in a time where I am concerned about the engineers we
> > are creating, where point & click seems to trump basic understanding +
> CLI
> > knowledge. My concern is when it all goes to hell at 3AM, do the next
> > generation of network engineers have the base fundamentals to understand
> > why iBGP isn't coming up, even though you can "ping" and IGP adjacencies
> > are up and stable?
> >
> Hopefully well end up in a world where all checks one can do to figure out
> why iBGP session is down along with suggested corrective actions will be
> coded in some network self-healing workflow.
> But to answer your question, probably no, cause current industry is
> systematically converting network engineers into coders.
>
> adam
>
>
>

RE: questions asked during network engineer interview

[adamv0025]

> Mark Tinka
> Sent: Thursday, July 23, 2020 5:04 AM
> 
> On 23/Jul/20 01:04, Brandon Martin wrote:
> 
> >
> > Of course, there's also plenty of folks out there without them or any
> > certs at all that are just as useful in practice.  Getting those
> > particular certifications does, however, seem to be a useful path to
> > learning things that are actually of use in the "real world".  I look
> > at such certificates similar to how I'd look at a 2- or 4-year degree
> > in a related IT field and just a somewhat different, and perhaps more
> > approachable for the self-coached or differently-learning, path.
> 
> We live in a time where I am concerned about the engineers we
> are creating, where point & click seems to trump basic understanding + CLI
> knowledge. My concern is when it all goes to hell at 3AM, do the next
> generation of network engineers have the base fundamentals to understand
> why iBGP isn't coming up, even though you can "ping" and IGP adjacencies
> are up and stable?
> 
Hopefully well end up in a world where all checks one can do to figure out why 
iBGP session is down along with suggested corrective actions will be coded in 
some network self-healing workflow. 
But to answer your question, probably no, cause current industry is 
systematically converting network engineers into coders. 

adam
   

Re: questions asked during network engineer interview

[Mark Tinka]

On 23/Jul/20 01:04, Brandon Martin wrote:
 
>
> Of course, there's also plenty of folks out there without them or any
> certs at all that are just as useful in practice.  Getting those
> particular certifications does, however, seem to be a useful path to
> learning things that are actually of use in the "real world".  I look
> at such certificates similar to how I'd look at a 2- or 4-year degree
> in a related IT field and just a somewhat different, and perhaps more
> approachable for the self-coached or differently-learning, path.

You get two kinds of folk re: certifications:

Those that want to pile up as many certifications as they can, and may
not know when to slow down to actually put those skills into production.

And those who can't wait to put what they have learned into practice,
sometimes at the expense of finding time to actually sit the exam.

It's been a while since I reviewed any certification programs for
network engineers. We live in a time where I am concerned about the
engineers we are creating, where point & click seems to trump basic
understanding + CLI knowledge. My concern is when it all goes to hell at
3AM, do the next generation of network engineers have the base
fundamentals to understand why iBGP isn't coming up, even though you can
"ping" and IGP adjacencies are up and stable?

Mark.

Re: questions asked during network engineer interview

[Mark Tinka]

On 23/Jul/20 00:55, Łukasz Bromirski wrote:

> And yes (to the main topic of this thread) - I have some certs.
> I understand people without certs tend to discard them as
> non-relevant or even toxic. Yes, I’ve met “paper” CCIEs,
> but also JNCIEs and I can see the point being made. I’ve
> met great minds (also on this list) without any networking
> certificates. I believe that until you see real person on the
> other side of table and not her/his cert(s), good chat and
> questions will remove all doubts. Everyone has to start
> somewhere and make those first errors, and being ‘expert’
> doesn’t mean you’re not making them anymore.

My experience has been very good with people that got their certificates
somewhere between the mid-to-late 90's and early-to-mid 2000's, and
opted not to renew them because they were too busy deploying and
operating real networks (that 3-year renewal requirement was a neat
trick). I'm not sure if there is a correlation in there.

From about 13 years ago, I met a number of engineers who specifically
sat for certifications because it was an immediate guarantee on a
minimum base salary in several companies, regardless of actual
experience. I lost my faith in automatically assuming the best from
CC-this or JN-that when a CCIE we hired at a previous job couldn't
design a system from scratch, all by himself. So I'll still give anyone
with a certificate the time of day, but it won't have any bearing on
their abilities, until we've had a real chat. My observations are just
that more of the hires I've done have been of those who have 15-year old
expired certifications, or none at all.

I have a few certifications, from 2003 and 2007. I tried to get more but
the Internet was moving way faster than I could study :-).

Mark.

Re: questions asked during network engineer interview

[Sabri Berisha]

- On Jul 22, 2020, at 4:04 PM, Brandon Martin lists.na...@monmotha.net 
wrote:

Hi,

> The CCIE and JNCIE (and perhaps other vendor equivalents) are some of
> the few vendor certs I've found often (though not always) meaningful.

Well, in the good old days when you could not pass an IE exam by simply taking a
bootcamp the week before... 

> Of course, there's also plenty of folks out there without them or any
> certs at all that are just as useful in practice.

I have the "old school" JNCIE-M. If anything, it's the troubleshooting under
pressure that's a skill that's being tested. Everyone could finish the lab
successfully in a week, doing it in 8 hours was the challenge.

Someone advertising a CCIE or JNCIE cert on their resume is raising my 
expectations
in terms of being able to have a solid understanding of at least one protocol. I
also like to talk about their journey through the program. This is where I'm 
able
to tell the difference between the ones that are passionate about it, and the
ones that had to pass the exam so their employer could get additional 
discounts..

Thanks,

Sabri

Re: questions asked during network engineer interview

[Brandon Martin]

On 7/22/20 6:55 PM, Łukasz Bromirski wrote:

And yes (to the main topic of this thread) - I have some certs.
I understand people without certs tend to discard them as
non-relevant or even toxic. Yes, I’ve met “paper” CCIEs,
but also JNCIEs and I can see the point being made. I’ve
met great minds (also on this list) without any networking
certificates. I believe that until you see real person on the
other side of table and not her/his cert(s), good chat and
questions will remove all doubts. Everyone has to start
somewhere and make those first errors, and being ‘expert’
doesn’t mean you’re not making them anymore.


The CCIE and JNCIE (and perhaps other vendor equivalents) are some of 
the few vendor certs I've found often (though not always) meaningful. 
If the candidate takes it upon themselves to really understand the why 
of what's going on in the prep and testing for those certs, it can be a 
very meaningful track.  Of course if they just answer cram, it's 
bordering on useless, but (and not having either I can't say this with 
certainty) those particular tests seem to try to make such cramming at 
minimum impractical if not impossible.


Of course, there's also plenty of folks out there without them or any 
certs at all that are just as useful in practice.  Getting those 
particular certifications does, however, seem to be a useful path to 
learning things that are actually of use in the "real world".  I look at 
such certificates similar to how I'd look at a 2- or 4-year degree in a 
related IT field and just a somewhat different, and perhaps more 
approachable for the self-coached or differently-learning, path.


At minimum, I think it's a useful jumping off point in an interview for 
a candidate who has paper experience but not a lot of real-world 
experience:  "So, tell me about a particularly dicey interoperability 
scenario you encountered while going for your CCIE?  What steps did you 
take to troubleshoot and either solve or work around it?" or similar.

--
Brandon Martin

Re: questions asked during network engineer interview

[Łukasz Bromirski]

Adam,

> On 21 Jul 2020, at 19:13, Mark Tinka  wrote:
> On 21/Jul/20 18:39, adamv0...@netconsultings.com wrote:
>> Little you two know about SDN, please read the following presentation from 
>> Scott Shenker and then get back here arguing what it is and what it is not: 
>> https://inst.eecs.berkeley.edu/~cs168/fa14/lectures/lec23-public.pdf
> 
> I'll pass, thanks. Already did my time in that rabbit hole.

Yeah. Also, I see great piece near end of the slide deck:

"We (Berkeley) are pushing SDNv2 which focuses on
 - General processing at the edge (middleboxes)
 - Very simple processing in the core
 - Support for third-party services (using mboxes)”

I believe I’ve seen this somewhere ;)

Are we reinventing tag switching?

Mind it, PDF is from 2014 and represents very naive approach to SDN (sorry, 
“SDNv2”).

And yes (to the main topic of this thread) - I have some certs.
I understand people without certs tend to discard them as
non-relevant or even toxic. Yes, I’ve met “paper” CCIEs,
but also JNCIEs and I can see the point being made. I’ve
met great minds (also on this list) without any networking
certificates. I believe that until you see real person on the
other side of table and not her/his cert(s), good chat and
questions will remove all doubts. Everyone has to start
somewhere and make those first errors, and being ‘expert’
doesn’t mean you’re not making them anymore.

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A

RE: questions asked during network engineer interview

[adamv0025]

> Jeff Bacon
> Sent: Wednesday, July 22, 2020 1:55 PM
> 
>  > Who said anything about boxing your tooling in to SDN tech? You  >
> described Software Defined Networking as a rabbit hole and snake oil.
>  > It isn't. It's a class of tools in the networking toolbox and an  > 
> increasingly
> useful one.
> 
> As it is, we have marketing people sticking "SDN" onto every bloody thing
> that comes along in the hopes that it'll better catch the attention of someone
> without enough of a clue that they'll cough up (and leave someone else to
> figure out what to do with it). I freely admit that's just what they do and
> expecting them to do anything different is wishful thinking, but I don't see
> any of us doing anything about it except creating long email chains wherein
> we just keep trying to munge apples and oranges together. :)
> 
I suggest we educate users so they can make better decisions on what tool to 
use for what job and not get confused in all the marketing jive around SDN.
Blueprint: MEF-SDN/NFV Certification Exam:
https://wiki.mef.net/pages/viewpage.action?pageId=75990347
- has a pretty good list of self-study material, don't worry you might have 
read a lot of those books already.

adam

Re: questions asked during network engineer interview

[Jeff Bacon]

> Who said anything about boxing your tooling in to SDN tech? You
> described Software Defined Networking as a rabbit hole and snake oil.
> It isn't. It's a class of tools in the networking toolbox and an
> increasingly useful one.

My toolbox in the garage has torque wrenches and allen wrenches and a 
GS-911 for talking to the Motronic on my bike, too. It's a pretty useful 
toolbox. I use all of them. I don't keep them all in the same drawer of 
the toolbox, though. Guessing you don't either. Or if you do, I 
*probably* don't want you working on my bike.


I for one would be happy if someone came up with some different acronyms 
and subdivide the "world of SDN" into some number of 
sub-techonologies/practices that were at least a little more cohesive 
with each other so then at least we'd know what keywords to fit into our 
news feeds so we could pay better attention to the bits that are more 
relevant to where we are. Ansible/netmiko/+CI/CD 
applied to kit (and people) does not resemble OpenDaylight or what 
hyperscalers are doing with DPDK on cards or the Microsoft FPGA-NIC 
trickery except in the broadest of views. All are good. Sure, they all 
belong in the toolbox. But maybe not in the same drawer.


As it is, we have marketing people sticking "SDN" onto every bloody 
thing that comes along in the hopes that it'll better catch the 
attention of someone without enough of a clue that they'll cough up (and 
leave someone else to figure out what to do with it). I freely admit 
that's just what they do and expecting them to do anything different is 
wishful thinking, but I don't see any of us doing anything about it 
except creating long email chains wherein we just keep trying to munge 
apples and oranges together. :)


-bacon

RE: questions asked during network engineer interview

[adamv0025]

> William Herrin
> Sent: Tuesday, July 21, 2020 8:21 PM
> 
> On Mon, Jul 20, 2020 at 9:57 PM Mark Tinka 
> wrote:
> > Suffice it to say, to this day, we still don't know what SDN means to
> > us, hehe.
> 
> Hi Mark,
> 
> The Software Defined Network concept started as, "Let's use commodity
> hardware running commodity operating systems to form the control plane
> for our network devices." The concept has expanded somewhat to: "Lets use
> commodity hardware running commodity operating systems AS our network
> devices." For example, if you build a high-rate firewall with DPDK on Linux,
> that's now considered SDN since its commodity hardware, commodity OS
> and custom packet handling (DPDK) that skips the OS.
> 
The higher level takeaway would be: 
"Modularity based on abstraction is the way things get done”
− Barbara Liskov

Abstractions -> Interfaces -> Modularity
This applies at the individual device level as well as you described above, 
however I'd say that application of these principles at the network-wide level 
is also very beneficial to service providers, (Device -> Network -> Service -> 
Product -> Offer).
This vision was first realized by AT in their ECOMP framework which (along 
with Open-O) is now morphed to ONAP. This idea has now been adopted by many 
service providers as well as commercial products.  
  
adam

RE: questions asked during network engineer interview

[adamv0025]

> From: Mel Beckman 
> Sent: Tuesday, July 21, 2020 9:48 PM
> 
> The problem is your door is stuck in 2014 :)
> 
> A lot has happened in the last six years.
> 
Yeah but if you won't get the basics (or fundamental problems in networking as 
a discipline that SDN is trying to solve) as nicely illustrated by Scott 
Shenker in that preso, you won't understand what modern SDN forks are about.

adam


  

Re: questions asked during network engineer interview

[Mark Tinka]

On 22/Jul/20 10:10, William Herrin wrote:

> Who said anything about boxing your tooling in to SDN tech? You
> described Software Defined Networking as a rabbit hole and snake oil.
> It isn't. It's a class of tools in the networking toolbox and an
> increasingly useful one.

Okay.

Mark.

Re: questions asked during network engineer interview

[William Herrin]

On Wed, Jul 22, 2020 at 12:41 AM Mark Tinka  wrote:
> I'll try this again...
>
> There will be tooling required to operate your network. Cloud,
> connectivity, content, e.t.c.
>
> The tooling will help the operator accomplish the task required as
> efficiently as possible, as long as they keep investing in and improving it.
>
> I don't want to box that tooling into "SDN tech". It is tooling. It may
> or may not smell like "SDN". All I care about is that it helps me
> achieve my objectives. If it is internal to my operation and not
> standardized with a ton of other operators, that's fine too.

Hi Mark,

Who said anything about boxing your tooling in to SDN tech? You
described Software Defined Networking as a rabbit hole and snake oil.
It isn't. It's a class of tools in the networking toolbox and an
increasingly useful one.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: questions asked during network engineer interview

[William Herrin]

On Tue, Jul 21, 2020 at 9:50 AM  wrote:
> One can't be an expert in many areas, (like CCIE-everything... folks)
> Same as Usain Bolt can't swim like Michael Phelps...

Polymaths are a thing but they have better use for the space on their
resumes than telling you about the certificates they hold.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: questions asked during network engineer interview

[Mark Tinka]

On 22/Jul/20 01:41, William Herrin wrote:

> I suppose it depends what you're trying to accomplish. If you're a
> hosting provider and you want to provide a capability both similar to
> AWS VPCs and strong enough to not be a joke, you won't get there on
> the tools Linux or VMWare provide. You'll have to invest in SDN tech.
> If you're hooking up residential subscribers to the Internet... it's
> less obvious how SDN would be of use to you.

I'll try this again...

There will be tooling required to operate your network. Cloud,
connectivity, content, e.t.c.

The tooling will help the operator accomplish the task required as
efficiently as possible, as long as they keep investing in and improving it.

I don't want to box that tooling into "SDN tech". It is tooling. It may
or may not smell like "SDN". All I care about is that it helps me
achieve my objectives. If it is internal to my operation and not
standardized with a ton of other operators, that's fine too.

Mark.

Re: questions asked during network engineer interview

[Mark Tinka]

On 22/Jul/20 02:35, Owen DeLong wrote:

> That word advantage… I do not think it means what you appear to think it means
> in this context. At least not based on some of my experiences with some
> of their implementations of certain basic networking features.

The context of "advantage" is not on the quality of the output, but on
the availability of resources for non-vendor shops.

Mark.

Re: questions asked during network engineer interview

[Valdis Klētnieks]

On Tue, 21 Jul 2020 23:04:30 +0200, Robert Raszuk said:

> attempt to open innovation into networking ... allowing one to invent
> protocols at will as well as setup forwarding tables with arbitrary

All of which either get layered onto port 443 or you have to wait for your CGNAT
vendor to provide an ALG for it. :)

(I'll just note that I've seen almost no overlap between the SDN crew, and
things like Google deciding to create and deploy QUIC. :)


pgpXD_TFQuvU8.pgp
Description: PGP signature

Re: questions asked during network engineer interview

[Owen DeLong]

> On Jul 21, 2020, at 2:58 PM, Mark Tinka  wrote:
> 
> 
> 
> On 21/Jul/20 22:20, Nick Hilliard wrote:
>  
>> 
>> IOW, it works if you have a large and homogeneous enough network with
>> a sufficiently narrowly product portfolio that you can justify the
>> cost of getting enough programming skill to make the cost/benefit
>> ratio work.
>> 
>> Some networks are like this; many aren't.
>> 
>> In fairness, most networks would benefit from some degree of automation.
> 
> We all could benefit from a sufficient degree of automation, whatever
> that means to you.
> 
> That the cloud bags can throw warm bodies at the problem even more than
> traditional vendors can is an advantage unique to them, even though they
> are not network service providers in the strict sense of the term. This
> is what leads to the divergence in our expectations, to some extent.

That word advantage… I do not think it means what you appear to think it means
in this context. At least not based on some of my experiences with some
of their implementations of certain basic networking features.

Owen

Re: questions asked during network engineer interview

[William Herrin]

On Tue, Jul 21, 2020 at 2:55 PM Mark Tinka  wrote:
> For the avoidance of doubt, "we still don't know what SDN means to us"
> means "we are not sold on the snake oil".

Hi Mark,

I suppose it depends what you're trying to accomplish. If you're a
hosting provider and you want to provide a capability both similar to
AWS VPCs and strong enough to not be a joke, you won't get there on
the tools Linux or VMWare provide. You'll have to invest in SDN tech.
If you're hooking up residential subscribers to the Internet... it's
less obvious how SDN would be of use to you.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: questions asked during network engineer interview

[Mark Tinka]

On 21/Jul/20 22:20, Nick Hilliard wrote:
 
>
> IOW, it works if you have a large and homogeneous enough network with
> a sufficiently narrowly product portfolio that you can justify the
> cost of getting enough programming skill to make the cost/benefit
> ratio work.
>
> Some networks are like this; many aren't.
>
> In fairness, most networks would benefit from some degree of automation.

We all could benefit from a sufficient degree of automation, whatever
that means to you.

That the cloud bags can throw warm bodies at the problem even more than
traditional vendors can is an advantage unique to them, even though they
are not network service providers in the strict sense of the term. This
is what leads to the divergence in our expectations, to some extent.

Mark.

Re: questions asked during network engineer interview

[Mark Tinka]

On 21/Jul/20 21:21, William Herrin wrote:

> The Software Defined Network concept started as, "Let's use commodity
> hardware running commodity operating systems to form the control plane
> for our network devices." The concept has expanded somewhat to: "Lets
> use commodity hardware running commodity operating systems AS our
> network devices." For example, if you build a high-rate firewall with
> DPDK on Linux, that's now considered SDN since its commodity hardware,
> commodity OS and custom packet handling (DPDK) that skips the OS.
>
> This is happening a lot in the big shops like Amazon that can afford
> to employ software developers to write purpose-built network code.

It's possible that I wasn't clear.

For the avoidance of doubt, "we still don't know what SDN means to us"
means "we are not sold on the snake oil".

Mark.

Re: questions asked during network engineer interview

[Robert Raszuk]

Bill,

> The Software Defined Network concept started as, "Let's use commodity
> hardware running commodity operating systems to form the control plane
> for our network devices."

That's not exactly the real beginning ... the above is more like oh where
do we plug this SDN into and how do we sell it :)

The last churn of SDN as I recall and as explained by Nick McKeown was an
attempt to open innovation into networking ... allowing one to invent
protocols at will as well as setup forwarding tables with arbitrary
switching/routing capabilities as student or operator would only like to
imagine.

That's when the OF was born (with various versions of it) to allow the
hardware and software decoupling.

Well I guess that experiment can be considered as completed today :)

Best,
R.


On Tue, Jul 21, 2020 at 9:22 PM William Herrin  wrote:

> On Mon, Jul 20, 2020 at 9:57 PM Mark Tinka  wrote:
> > Suffice it to say, to this day, we still don't know what SDN means to
> > us, hehe.
>
> Hi Mark,
>
> The Software Defined Network concept started as, "Let's use commodity
> hardware running commodity operating systems to form the control plane
> for our network devices." The concept has expanded somewhat to: "Lets
> use commodity hardware running commodity operating systems AS our
> network devices." For example, if you build a high-rate firewall with
> DPDK on Linux, that's now considered SDN since its commodity hardware,
> commodity OS and custom packet handling (DPDK) that skips the OS.
>
> This is happening a lot in the big shops like Amazon that can afford
> to employ software developers to write purpose-built network code.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: questions asked during network engineer interview

[Mel Beckman]

Nick,

SDN works very well even for tiny networks. Look at Ubiquiti’s SDN controller. 
Yes, it requires proprietary hardware (proving SDN isn’t only for commodity 
hardware). But it can scale a network of a single switch up to hundreds of 
switches with a single point of configuration. You want a new VLAN across the 
entire network? It’s a couple clicks. Want to deploy an new SSID in one 
department? A few more clicks. It’s very well designed for small- and mid-sized 
networks. 

Bigger networks use other products. But there is an SDN solution off-the-shelf 
today for every size. 

-mel via cell

> On Jul 21, 2020, at 1:22 PM, Nick Hilliard  wrote:
> 
> William Herrin wrote on 21/07/2020 20:21:
>> This is happening a lot in the big shops like Amazon that can afford
>> to employ software developers to write purpose-built network code.
> 
> IOW, it works if you have a large and homogeneous enough network with a 
> sufficiently narrowly product portfolio that you can justify the cost of 
> getting enough programming skill to make the cost/benefit ratio work.
> 
> Some networks are like this; many aren't.
> 
> In fairness, most networks would benefit from some degree of automation.
> 
> Nick
> 

Re: questions asked during network engineer interview

[Mel Beckman]

Brandon,

The problem is your door is stuck in 2014 :)

A lot has happened in the last six years. 

-mel via cell

> On Jul 21, 2020, at 10:26 AM, "adamv0...@netconsultings.com" 
>  wrote:
> 
> 
>> 
>> From: Mark Tinka 
>> Sent: Tuesday, July 21, 2020 6:14 PM
>> 
>>> On 21/Jul/20 18:39, adamv0...@netconsultings.com wrote:
>>> Little you two know about SDN, please read the following presentation
>> from Scott Shenker and then get back here arguing what it is and what it is
>> not: https://inst.eecs.berkeley.edu/~cs168/fa14/lectures/lec23-public.pdf
>> 
>> I'll pass, thanks. Already did my time in that rabbit hole.
>> 
> Well  "I can only show you the door. You're the one that has to walk through 
> it."  ;)
> 
> adam
> 

Re: questions asked during network engineer interview

[Nick Hilliard]

William Herrin wrote on 21/07/2020 20:21:

This is happening a lot in the big shops like Amazon that can afford
to employ software developers to write purpose-built network code.


IOW, it works if you have a large and homogeneous enough network with a 
sufficiently narrowly product portfolio that you can justify the cost of 
getting enough programming skill to make the cost/benefit ratio work.


Some networks are like this; many aren't.

In fairness, most networks would benefit from some degree of automation.

Nick

Re: questions asked during network engineer interview

[William Herrin]

On Mon, Jul 20, 2020 at 9:57 PM Mark Tinka  wrote:
> Suffice it to say, to this day, we still don't know what SDN means to
> us, hehe.

Hi Mark,

The Software Defined Network concept started as, "Let's use commodity
hardware running commodity operating systems to form the control plane
for our network devices." The concept has expanded somewhat to: "Lets
use commodity hardware running commodity operating systems AS our
network devices." For example, if you build a high-rate firewall with
DPDK on Linux, that's now considered SDN since its commodity hardware,
commodity OS and custom packet handling (DPDK) that skips the OS.

This is happening a lot in the big shops like Amazon that can afford
to employ software developers to write purpose-built network code.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: questions asked during network engineer interview

[Mark Tinka]

On 21/Jul/20 19:26, adamv0...@netconsultings.com wrote:

> Well  "I can only show you the door. You're the one that has to walk through 
> it."  ;)

You misunderstand me, Adam. I am not averse to learning new things.

What I am saying is I've spent 10 years on this road, and the summaries
you see me providing on this list are the most simplified conclusions
that are informed by a decade of this dance.

Seeing the bigger picture is, many times, as important as seeing the
detail. I don't expect you (or many) to share my point of view. And
that's okay, as long as we keep the Internet running.

Mark.

Re: questions asked during network engineer interview

[Brandon Martin]

On 7/21/20 12:55 AM, Mark Tinka wrote:

Suffice it to say, to this day, we still don't know what SDN means to
us, hehe.


I think that's part of the problem.  It means too many different things 
to different people.  Much of what people refer to SDN is useful, albeit 
often pre-existing before the SDN craze...you just have to know what it is.


Reminds me of the early days of ".NET" at Microsoft.  Everything was 
".NET", and eventually it became an actual thing.

--
Brandon Martin

RE: questions asked during network engineer interview

[adamv0025]

> From: Mark Tinka 
> Sent: Tuesday, July 21, 2020 6:14 PM
> 
> On 21/Jul/20 18:39, adamv0...@netconsultings.com wrote:
> > Little you two know about SDN, please read the following presentation
> from Scott Shenker and then get back here arguing what it is and what it is
> not: https://inst.eecs.berkeley.edu/~cs168/fa14/lectures/lec23-public.pdf
> 
> I'll pass, thanks. Already did my time in that rabbit hole.
> 
Well  "I can only show you the door. You're the one that has to walk through 
it."  ;)

adam

Re: questions asked during network engineer interview

[Mark Tinka]

On 21/Jul/20 18:39, adamv0...@netconsultings.com wrote:
> Little you two know about SDN, please read the following presentation from 
> Scott Shenker and then get back here arguing what it is and what it is not: 
> https://inst.eecs.berkeley.edu/~cs168/fa14/lectures/lec23-public.pdf

I'll pass, thanks. Already did my time in that rabbit hole.

Mark.

RE: questions asked during network engineer interview

[adamv0025]

> William Herrin
> Sent: Monday, July 20, 2020 9:02 PM
>
> On Mon, Jul 20, 2020 at 5:09 AM Mark Tinka 
> wrote:
> > We'll probably spend 95% of the time just talking about who they are,
> > and 5% on the role. That has worked well for me in the past decade,
> > and none of those hires had any "certificates" to impress me with,
> > even though those that didn't make it, did.
> 
> I find there's a strong INVERSE correlation between the quantity of
> certificates on an applicant's resume and their ability to do the job.
>
One can't be an expert in many areas, (like CCIE-everything... folks)
Same as Usain Bolt can't swim like Michael Phelps...
 

> I still have to laugh about the guy who let me know via his resume that he
> was certified in setting up Kentrox CSU/DSUs.
> 
Nice, did he also knew how to put a loop on a T1/T3 DACS (DCX) or how to do SNA 
to mainframe and then DLSW? :) very useful skills these days indeed. 
technology used to be much simpler. 


adam

RE: questions asked during network engineer interview

[adamv0025]

Little you two know about SDN, please read the following presentation from 
Scott Shenker and then get back here arguing what it is and what it is not: 
https://inst.eecs.berkeley.edu/~cs168/fa14/lectures/lec23-public.pdf

adam

Re: questions asked during network engineer interview

[Ben Cannon]

I come from the “we’ve had SDN for years, it’s called L2VPN” but I guess the 
rest of the world hasn’t been a carrier for 26yrs either.
-Ben

Ms. Benjamin PD Cannon, ASCE
6x7 Networks & 6x7 Telecom, LLC 
CEO 
b...@6by7.net 
"The only fully end-to-end encrypted global telecommunications company in the 
world.”
FCC License KJ6FJJ



> On Jul 20, 2020, at 9:55 PM, Mark Tinka  wrote:
> 
> 
> 
> On 20/Jul/20 23:59, Brandon Martin wrote:
> 
>> Pass given to those who cram them into a "certificates" or "specifics"
>> line or similar in order to get around HR filters, limit them to major
>> certs (or ones your HR dept. specifically demanded), and don't really
>> mention them otherwise.  Bear in mind as well that, even if your
>> hiring process doesn't demand them, others' will, and many people have
>> a standard-ish resume with application-specific cover letter.
> 
> When SDN was all the rage in the middle of the past decade, our HR
> department wanted to hire someone in this field and asked me what type
> of qualifications and certifications they should be looking for. Well, I
> told them to look for someone who had enough will and time to figure out
> what it means to us, and the patience to experiment, fail and experiment
> again, without losing any steam or confidence, and take a pass on any
> SDN certifications recommended by our "recruiting consultants".
> 
> We ended up hiring a regular (but very good) network engineer who had
> recently taken up an interest in understanding and writing software to
> perform repetitive tasks. It was just a shame they chose not join at the
> last minute, but we weren't the worse off for it either.
> 
> At the time, everyone and their arm rest were offering some kind of
> SDN-workshop-certification thingy.
> 
> Suffice it to say, to this day, we still don't know what SDN means to
> us, hehe.
> 
> Mark.
> 

Re: questions asked during network engineer interview

[Mark Tinka]

On 21/Jul/20 17:43, Mel Beckman wrote:
> Have any of those operators shipped an SDM product? If not, then of
> course, they are pre-SDN. Just like NASA is pre-commercial space
> launch :-)

It never occurred to me that SDN was the service provider product. Dang,
we've been doing it all wrong :-).

Mark.

Re: questions asked during network engineer interview

[Mel Beckman]

Have any of those operators shipped an SDM product? If not, then of course, 
they are pre-SDN. Just like NASA is pre-commercial space launch :-)

-mel via cell

On Jul 21, 2020, at 8:17 AM, Mark Tinka  wrote:



On 21/Jul/20 16:59, Mel Beckman wrote:


But SDN is NOT just ""SDN = some kind of automation””. Its centralized 
management with good automation built-in. Good automation means automation that 
orchestrates cohesive, correct network changes — and can roll them back — not 
just scripts that can spew configs into individual devices.

So operators who've been doing this for decades are, what? Pre-SDN :-).


And you say SDN consists of "bits of code and ideas coming out of these 
operators” as if that’s a bad thing. That’s how all innovation happens in IT.

I didn't say it was a bad thing; I said the gap to standardization will remain 
wide if we are not feeding off the full story.



Today's SDN has delivered on orchestration and good automation.You only have to 
shop and compare, the products are there and very powerful.

Oh, don't get me wrong - we've seen all the products. Evaluated a bunch. Not 
enough for me to write a cheque though; many of the vendors can't make their 
own minds up. But meh, YMMV.



But more germane to this discussion, I would expect any network engineer 
candidate to know all about SDN, know how various vendors implement it, and 
have experience using it.

You wouldn’t expect a bridge engineer to not be proficient in advanced 
computational modeling, would you? Or an electrical engineer to not understand 
field-programmable gate arrays? Or a chemical engineer ignorant of SCADA 
programmable logic controllers?

That’s the equivalent of an SDN-ignorant engineer in today’s market.

Well then show me the door to where the SDN-ignorants are gathering. I'll go 
join them for a laugh :-).

Seriously though, I'm not dismissing "SDN". I'm just saying we may not all 
agree on what it means for us. So let's spend more time on what we can agree 
on; how folk get there (SDN, or whatever name we dream up this decade) is up to 
them.

If we still struggle to implement a basic, but standard BCP-38/MANRS on a 
global scale, I think we may be shooting for the stars to standardize that 
other thing.

Mark.

Re: questions asked during network engineer interview

[Mark Tinka]

On 21/Jul/20 16:59, Mel Beckman wrote:

>
> But SDN is NOT just ""SDN = some kind of automation””. Its centralized
> management with /good /automation built-in. Good automation means
> automation that orchestrates cohesive, correct network changes — and
> can roll them back — not just scripts that can spew configs into
> individual devices.

So operators who've been doing this for decades are, what? Pre-SDN :-).


> And you say SDN consists of "bits of code and ideas coming out of
> these operators” as if that’s a bad thing. That’s how all innovation
> happens in IT.

I didn't say it was a bad thing; I said the gap to standardization will
remain wide if we are not feeding off the full story.


>
> Today's SDN has delivered on orchestration and good automation.You
> only have to shop and compare, the products are there and very powerful.

Oh, don't get me wrong - we've seen all the products. Evaluated a bunch.
Not enough for me to write a cheque though; many of the vendors can't
make their own minds up. But meh, YMMV.


>
> But more germane to this discussion, I would expect any network
> engineer candidate to know all about SDN, know how various vendors
> implement it, and have experience using it.
>
> You wouldn’t expect a bridge engineer to not be proficient in advanced
> computational modeling, would you? Or an electrical engineer to not
> understand field-programmable gate arrays? Or a chemical engineer
> ignorant of SCADA programmable logic controllers? 
>
> That’s the equivalent of an SDN-ignorant engineer in today’s market.

Well then show me the door to where the SDN-ignorants are gathering.
I'll go join them for a laugh :-).

Seriously though, I'm not dismissing "SDN". I'm just saying we may not
all agree on what it means for us. So let's spend more time on what we
can agree on; how folk get there (SDN, or whatever name we dream up this
decade) is up to them.

If we still struggle to implement a basic, but standard BCP-38/MANRS on
a global scale, I think we may be shooting for the stars to standardize
that other thing.

Mark.

Re: questions asked during network engineer interview

[Mel Beckman]

Mark,

But SDN is NOT just ""SDN = some kind of automation””. Its centralized 
management with good automation built-in. Good automation means automation that 
orchestrates cohesive, correct network changes — and can roll them back — not 
just scripts that can spew configs into individual devices. And you say SDN 
consists of "bits of code and ideas coming out of these operators” as if that’s 
a bad thing. That’s how all innovation happens in IT.

Today's SDN has delivered on orchestration and good automation.You only have to 
shop and compare, the products are there and very powerful.

But more germane to this discussion, I would expect any network engineer 
candidate to know all about SDN, know how various vendors implement it, and 
have experience using it.

You wouldn’t expect a bridge engineer to not be proficient in advanced 
computational modeling, would you? Or an electrical engineer to not understand 
field-programmable gate arrays? Or a chemical engineer ignorant of SCADA 
programmable logic controllers?

That’s the equivalent of an SDN-ignorant engineer in today’s market.

 -mel

On Jul 20, 2020, at 10:34 PM, Mark Tinka 
mailto:mark.ti...@seacom.com>> wrote:



On 21/Jul/20 07:12, Mel Beckman wrote:
Mark,

There are a slew of fine SDN products out there, from VMware NSX-T in big 
enterprise to Ubiquiti UniFiOS in SMBs, and lots of other products aimed at 
various market niches. What failed about the original SDN academic vision, more 
or less, was standardized, vendor-agnostic SDN based on protocols such as 
OpenFlow. Sure, a standardized platform would be nice, but you can’t blame 
vendors for wanting to differentiate their products to gain marketshare. 
OpenFlow never really delivered in a way that any vendors could build a 
competitive product around. HP tried, but, well, here we are.

The goal SDN was created for was centralized management with good automation 
built in. Nobody ever promised single-pane management of multiple vendors’ 
network elements. Nobody promised that because there is no way to make a living 
selling that.

And despite taking the long route to get to that conclusion, that is
essentially what we've had to learn the hard way.

If "SDN = some kind of automation", this isn't new. Operators abound
have been "automating" for years... decades, even. It's just that their
solutions have been internal, either entirely homegrown, or cobbled
together with hand-written + external vendor-provided systems. These
systems have grown and become significantly large to the extent that it
makes it difficult for these "established" operators to want to
participate in "standardizing" what they already have, or openly
contribute to a standardization process because, well, they don't really
have a problem to solve.

Moreover, a lot of the drive on these "SDN thingies" is bits of code and
ideas coming out of these operators (notably, the cloud bags [boys &
girls]), when they are feeling generous to share what they've been
working on with the community. Regardless of what they share, they are
probably 10 years ahead of what we get to see. How do you expect to
standardize a gap like that?

Ultimately, I don't think the industry will reasonably agree on
standardization of this process. 40 years of the Internet and you still
can't "buy" an NMS that "just works". That should tell you something :-).

We should be spending more time encouraging folk on how to simplify
repetitive tasks. The actual solutions they decide to implement to get
there should be left to them. I don't want to waste another decade on this.

Last week's Cloudflare incident should remind us how uncomplicated this
is. The problems we need to solve are as simple now as they were 25
years ago. So let's not complicate it anymore than we need to.

Mark.

Re: questions asked during network engineer interview

[Nathan Stratton]

On Mon, Jul 20, 2020 at 4:45 PM Sander Steffann  wrote:

> > I find there's a strong INVERSE correlation between the quantity of
> > certificates on an applicant's resume and their ability to do the
> > job.
>
> Never got a certificate, don't want one either :)
>

That's what I said about high school, my parents were not thrilled, but at
least for me, it worked out.

-Nathan

Re: questions asked during network engineer interview

[Mark Tinka]

On 21/Jul/20 07:12, Mel Beckman wrote:
> Mark,
>
> There are a slew of fine SDN products out there, from VMware NSX-T in big 
> enterprise to Ubiquiti UniFiOS in SMBs, and lots of other products aimed at 
> various market niches. What failed about the original SDN academic vision, 
> more or less, was standardized, vendor-agnostic SDN based on protocols such 
> as OpenFlow. Sure, a standardized platform would be nice, but you can’t blame 
> vendors for wanting to differentiate their products to gain marketshare. 
> OpenFlow never really delivered in a way that any vendors could build a 
> competitive product around. HP tried, but, well, here we are.
>
> The goal SDN was created for was centralized management with good automation 
> built in. Nobody ever promised single-pane management of multiple vendors’ 
> network elements. Nobody promised that because there is no way to make a 
> living selling that.

And despite taking the long route to get to that conclusion, that is
essentially what we've had to learn the hard way.

If "SDN = some kind of automation", this isn't new. Operators abound
have been "automating" for years... decades, even. It's just that their
solutions have been internal, either entirely homegrown, or cobbled
together with hand-written + external vendor-provided systems. These
systems have grown and become significantly large to the extent that it
makes it difficult for these "established" operators to want to
participate in "standardizing" what they already have, or openly
contribute to a standardization process because, well, they don't really
have a problem to solve.

Moreover, a lot of the drive on these "SDN thingies" is bits of code and
ideas coming out of these operators (notably, the cloud bags [boys &
girls]), when they are feeling generous to share what they've been
working on with the community. Regardless of what they share, they are
probably 10 years ahead of what we get to see. How do you expect to
standardize a gap like that?

Ultimately, I don't think the industry will reasonably agree on
standardization of this process. 40 years of the Internet and you still
can't "buy" an NMS that "just works". That should tell you something :-).

We should be spending more time encouraging folk on how to simplify
repetitive tasks. The actual solutions they decide to implement to get
there should be left to them. I don't want to waste another decade on this.

Last week's Cloudflare incident should remind us how uncomplicated this
is. The problems we need to solve are as simple now as they were 25
years ago. So let's not complicate it anymore than we need to.

Mark.

Re: questions asked during network engineer interview

[Mel Beckman]

Mark,

There are a slew of fine SDN products out there, from VMware NSX-T in big 
enterprise to Ubiquiti UniFiOS in SMBs, and lots of other products aimed at 
various market niches. What failed about the original SDN academic vision, more 
or less, was standardized, vendor-agnostic SDN based on protocols such as 
OpenFlow. Sure, a standardized platform would be nice, but you can’t blame 
vendors for wanting to differentiate their products to gain marketshare. 
OpenFlow never really delivered in a way that any vendors could build a 
competitive product around. HP tried, but, well, here we are.

The goal SDN was created for was centralized management with good automation 
built in. Nobody ever promised single-pane management of multiple vendors’ 
network elements. Nobody promised that because there is no way to make a living 
selling that.

THAT’S what SDN means to you. :)

 -mel


> On Jul 20, 2020, at 9:55 PM, Mark Tinka  wrote:
> 
> 
> 
> On 20/Jul/20 23:59, Brandon Martin wrote:
> 
>> Pass given to those who cram them into a "certificates" or "specifics"
>> line or similar in order to get around HR filters, limit them to major
>> certs (or ones your HR dept. specifically demanded), and don't really
>> mention them otherwise.  Bear in mind as well that, even if your
>> hiring process doesn't demand them, others' will, and many people have
>> a standard-ish resume with application-specific cover letter.
> 
> When SDN was all the rage in the middle of the past decade, our HR
> department wanted to hire someone in this field and asked me what type
> of qualifications and certifications they should be looking for. Well, I
> told them to look for someone who had enough will and time to figure out
> what it means to us, and the patience to experiment, fail and experiment
> again, without losing any steam or confidence, and take a pass on any
> SDN certifications recommended by our "recruiting consultants".
> 
> We ended up hiring a regular (but very good) network engineer who had
> recently taken up an interest in understanding and writing software to
> perform repetitive tasks. It was just a shame they chose not join at the
> last minute, but we weren't the worse off for it either.
> 
> At the time, everyone and their arm rest were offering some kind of
> SDN-workshop-certification thingy.
> 
> Suffice it to say, to this day, we still don't know what SDN means to
> us, hehe.
> 
> Mark.
> 

Re: questions asked during network engineer interview

[Mark Tinka]

On 20/Jul/20 23:59, Brandon Martin wrote:

> Pass given to those who cram them into a "certificates" or "specifics"
> line or similar in order to get around HR filters, limit them to major
> certs (or ones your HR dept. specifically demanded), and don't really
> mention them otherwise.  Bear in mind as well that, even if your
> hiring process doesn't demand them, others' will, and many people have
> a standard-ish resume with application-specific cover letter.

When SDN was all the rage in the middle of the past decade, our HR
department wanted to hire someone in this field and asked me what type
of qualifications and certifications they should be looking for. Well, I
told them to look for someone who had enough will and time to figure out
what it means to us, and the patience to experiment, fail and experiment
again, without losing any steam or confidence, and take a pass on any
SDN certifications recommended by our "recruiting consultants".

We ended up hiring a regular (but very good) network engineer who had
recently taken up an interest in understanding and writing software to
perform repetitive tasks. It was just a shame they chose not join at the
last minute, but we weren't the worse off for it either.

At the time, everyone and their arm rest were offering some kind of
SDN-workshop-certification thingy.

Suffice it to say, to this day, we still don't know what SDN means to
us, hehe.

Mark.

Re: questions asked during network engineer interview

[Brandon Martin]

On 7/20/20 4:02 PM, William Herrin wrote:

I find there's a strong INVERSE correlation between the quantity of
certificates on an applicant's resume and their ability to do the job.
I still have to laugh about the guy who let me know via his resume
that he was certified in setting up Kentrox CSU/DSUs.


Pass given to those who cram them into a "certificates" or "specifics" 
line or similar in order to get around HR filters, limit them to major 
certs (or ones your HR dept. specifically demanded), and don't really 
mention them otherwise.  Bear in mind as well that, even if your hiring 
process doesn't demand them, others' will, and many people have a 
standard-ish resume with application-specific cover letter.


--
Brandon Martin

Re: questions asked during network engineer interview

[Randy Bush]

>> I find there's a strong INVERSE correlation between the quantity of
>> certificates on an applicant's resume and their ability to do the
>> job.
> 
> Never got a certificate, don't want one either :)

but now you can get an ncc certificate, certifying that you can actually
use their product.  how can we resist?

randy

Re: questions asked during network engineer interview

[Sander Steffann]

> I find there's a strong INVERSE correlation between the quantity of
> certificates on an applicant's resume and their ability to do the
> job.

Never got a certificate, don't want one either :)
Sander



signature.asc
Description: This is a digitally signed message part

Re: questions asked during network engineer interview

[Michael Thomas]

On 7/20/20 1:02 PM, William Herrin wrote:

On Mon, Jul 20, 2020 at 5:09 AM Mark Tinka  wrote:

We'll probably spend 95% of the time just talking about who they are,
and 5% on the role. That has worked well for me in the past decade, and
none of those hires had any "certificates" to impress me with, even
though those that didn't make it, did.

I find there's a strong INVERSE correlation between the quantity of
certificates on an applicant's resume and their ability to do the job.
I still have to laugh about the guy who let me know via his resume
that he was certified in setting up Kentrox CSU/DSUs.


It's like all of these programming bootcamps that are cropping up these 
days. I'd frankly be a lot more impressed by somebody who is green but 
self-taught. That at least shows initiative.


Mike

Re: questions asked during network engineer interview

[William Herrin]

On Mon, Jul 20, 2020 at 5:09 AM Mark Tinka  wrote:
> We'll probably spend 95% of the time just talking about who they are,
> and 5% on the role. That has worked well for me in the past decade, and
> none of those hires had any "certificates" to impress me with, even
> though those that didn't make it, did.

I find there's a strong INVERSE correlation between the quantity of
certificates on an applicant's resume and their ability to do the job.
I still have to laugh about the guy who let me know via his resume
that he was certified in setting up Kentrox CSU/DSUs.

-Bill

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: questions asked during network engineer interview

[Mark Tinka]

On 14/Jul/20 22:36, William Herrin wrote:

>
> You know what job you're interviewing for. What you choose to talk
> about tells me volumes about how you think.

I'm for this, too.

I just like to talk to people, about themselves, and figure out who they
are as a person.

Once in a while, I'll throw in a question about the role they are
interviewing for, let them talk about it, and then go back to just
talking to them, about themselves, as a person.

It's a different world nowadays to what it was 20 years ago. There is so
much information out there to make anyone an expert, so I'm not keen on
turning interviews into finals exam rooms. A person's essential
character is far more appealing to me, since their ability to embrace
and adapt to changes in culture is why they are most likely to be a good
fit.

We'll probably spend 95% of the time just talking about who they are,
and 5% on the role. That has worked well for me in the past decade, and
none of those hires had any "certificates" to impress me with, even
though those that didn't make it, did.

Mark.

Re: questions asked during network engineer interview

[Mark Tinka]

On 14/Jul/20 22:14, Matthew Petach wrote:

>
> I *love* questions like that, because I can immediately respond back
> with "well, that depends; did your sysadmin configure rfc1323
> extension support in your TCP stack?  Is SACK enabled?  What about
> window scaling?  Does your OS do dynamic buffer tuning for TCP, or are
> the values locked in at start time?"
>
> Depending on how the interviewer responds gives me a pretty good idea
> how much clue the people I'd be working with have, and how well they
> work collaboratively even with people they don't really know.  If they
> respond well on their feet, and give me better inputs, I respond with
> a better answer.
>
> If they say "It doesn't matter", then I respond by saying "See, that's
> why things aren't working so well for you here; you don't really
> understand how far down the rabbit hole goes", and respectfully ask to
> end the interview before we waste any more of each other's time.
>
> I *love* teaching--but only with people who are open to learning.

+1.

Mark.

Re: questions asked during network engineer interview

[Sabri Berisha]

- On Jul 14, 2020, at 1:14 PM, Matthew Petach  
wrote: 

Hi,

> Depending on how the interviewer responds gives me a pretty good idea how much
> clue the people I'd be working with have, and how well they work
> collaboratively even with people they don't really know. If they respond well
> on their feet, and give me better inputs, I respond with a better answer.

This is exactly what I would be looking for when I interview. Make me regret
asking the question, and you'll have my vote. I like to work with people that 
are smarter than me.

But I also prefer generic questions that are open to the candidate's 
imagination.
Not so much to make their lives difficult, but to see how they think. For 
example,
I'll draw a small network topology and ask which protocol they prefer (most of 
the
time that's either OSPF or BGP). "Ok, fully configured network, after a power 
outage the power is back on. Tell me what happens and how routes are exchanged".

OSPF areas? EBGP or IBGP? You make it up, whatever you're comfortable with. If 
they
start explaining how R1 starts transmitting hello packets, you know that they 
think
different from someone that starts to explain how R3 and R4 are ABRs. But 
whatever
answer I get, I dig until I get an "I don't know". Like "ok, what information is
contained in that hello packet?". Etc, etc. But I expect nobody to know 
everything,
especially not stuff that can be easily googled.

I've been on both sides many times, and like other commenters say, an interview
goes both ways. 

Thanks,

Sabri

Re: questions asked during network engineer interview

[Joe Hamelin]

My first question was always: Who was Jon Postel?
--
Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474




>
>

Re: questions asked during network engineer interview

[Here At InfoChambers]

On 7/14/20 10:49 AM, Michael Thomas wrote:



I had a screening interview at Google where the screener asked some 
ridiculous question that nobody not straight out of school would know, 
and even then not likely. I was like, wtf? If that's how they treat 
candidates -- and from everything I've heard it is -- I want nothing to 
do with them, and flat out refused their recruiters a dozen time 
afterward even though they pleaded that they've changed. Sorry, 
interviewing is a two-way street.


   I had a job where my department was very suddenly informed that 
rather than continuing with the quite successful training and 
introduction program that we had for our new people, instead A Trainer 
was required.


   After some bit we wound up with someone who definitely did not train 
people. Instead he spent his time making narcissistic videos, which were 
declared to be mandatory viewing for all in the department, and were 
totally useless for the work we were doing.


   In time, everyone actually getting the work done either ran for the 
door or finally got fired in waves.


   Somewhat in parallel, LinkedIn has been sending me begging emails 
demanding that I pay attention to it.  When I've logged in, I've been 
given displays based on where I've worked.


   One of the displays that pops up is a statement that the utter flake 
of a non-trainer now has a job which claims that he does "educational 
development", or something like that . . . .  at Google.


Sol

Re: questions asked during network engineer interview

[Andrey Khomyakov]

I was once asked at a FANG interview how I would affect incoming traffic using 
BGP. I listed the usual offenders like AS path and med. He kept asking how 
else, to which after pondering I said that I cant think of other ways right 
now. He was insisting I find one, so I theorized on using more specific prefix 
even though that’s technically not a BGP method. I think that was when he 
decided I failed, and I decided that he wanted me to name a creative method he 
himself used at his megascaler. Considering I never had to even think about 
solving problems at their scale I think that was just dumb to insist I come up 
with it. 
I’ll never know what that magical method is since he didn’t actually give me 
the answer I didn’t know ¯\_(ツ)_/¯ 
In my mind I’d rather a person admit to not knowing than spit bull at you with 
confidence. Admitting not knowing means you’ll know to look it up or ask 
someone. Bullsh*tting means you’ll probably implement some insane thing and not 
consult anyone about it.

The interview in general seemed to be more about technical nerd knobs of random 
technologies and less about how I think about problems. 

My take is that nerd knobs can be taught and/or looked up. How a person thinks 
and dissects the problems at hand can hardly be changed easily.

The question about “what happens when you enter google.com into your browser” 
is probably my favorite and I ask it to candidates every time. That and “how 
can you confirm a remote system is listening on a given TCP port”. Idk what it 
is that confuses people, but close to zero people answered “telnet or netcat to 
that port” and most of them went down the “I ssh into the system” or “I look in 
the firewall” or “I netstat”.

Another one is “what is the summary prefix for 10.0.0.0/24 and 10.0.1.0/24”. 
So.many.minds.blown! Some ask for pen and paper. Others just start doing binary 
conversions out loud

Turns out there are as many bad candidates as there are interviewers. I 
consider myself a bad interviewer so I try to shy away from interviewing 
candidates if I can. And based on this email chains so far it seems like there 
is not an agreed upon good interview method.

---
Sent from mobile

> On Jul 14, 2020, at 10:34, Owen DeLong  wrote:
> 
> 
> 
>>> On Jul 14, 2020, at 10:20 , Michael Thomas  wrote:
>>> 
>>> 
>>> 
>>> On 7/13/20 8:16 PM, Greg Skinner via NANOG wrote:
 If you ever decide to revisit this subject, I recall it was covered here 
 in this thread started by Bill Herrin.
 
 My general feelings on the subject of tech interviews are summarized in 
 the “interview anti-loop” section of this article by Steve Yegge.   
 Although it is targeted to people seeking software engineering jobs at 
 FANG (and FANG-like) companies, IMO the general tone is applicable to 
 other tech careers, even network engineering.  I have seen numerous 
 articles (and subsequent discussions) on this subject on forums such as 
 Quora, Medium, and Hacker News.
>>> 
>>> That blog post is everything that is wrong with software interviews. It's 
>>> fine to ask intricate algorithm questions for somebody fresh out of school 
>>> because what else are you going to ask them? But for somebody who's years 
>>> out of school and has lots of experience, the intricate details of various 
>>> algorithms fade especially ones that you don't use very often, or are 
>>> embedded in library routines you'd be fired for if you tried to reinvent 
>>> them. Telling people they have to go back to school for stuff they won't be 
>>> using on the job is offensive.
>>> 
>> 
>> I once failed a network engineering interview because I couldn’t recite the 
>> OSPF LSA types by number from memory. It was fine, the fact that was a key 
>> question in the interview convinced me that I had no more desire to work 
>> there than they had to hire me.
>> My personal method is to devise a problem and actually work with them... 
>> because that's what I (or others) are going to be doing. How well can they 
>> get the requirements? How do they zero in on how to solve it? You can take 
>> this as deep or shallow as you like. Often I'd give it as a homework 
>> assignment if I liked them.
>> 
> I prefer this approach as well. Depending on the level of interviewee, I like 
> to pull up a real world scenario from my past and see how they approach it. 
> I’m not nearly as concerned if they get to the right solution as I want to 
> see how they go about identifying and solving the problem. Do they ask 
> questions that narrow their focus and identify the issue, or do they start 
> trying random things hoping to stumble across a solution without 
> understanding the problem?
> 
> The former moves on to the next steps towards employment. The latter is 
> dropped from consideration.
>> My personal theory is software interviewing is basically a hazing ritual 
>> where the interviewers are trying to fluff their own privates, and it's 
>> almost to a 

Re: questions asked during network engineer interview

[Mehmet Akcin]

Should I do another session let’s say tomorrow and y’all join live and
share your thoughts? ;-)

On Tue, Jul 14, 2020 at 14:24 Miles Fidelman 
wrote:

> On 7/14/20 4:14 PM, Matthew Petach wrote:
>
>
>
> On Tue, Jul 14, 2020, 11:00 Ahmed elBorno  wrote:
>
>> 15 years ago, I applied to a network admin role at Google, it was for
>> their corporate office, not even the production network.
>>
>> I had less than two years experience.
>>
>> The interviewer asked me:
>> [...]
>> 2) If we had a 1GB file that we need to transfer between America and
>> Europe, how much time do we need, knowing that we start with a TCP size of X
>>
>
> Well, the first question is the available end-to-end bandwidth.  Pretty
> much everything else is irrelevant.
>
> Of course, I might ask them what they mean by "size."
>
> Miles Fidelman
>
> --
> In theory, there is no difference between theory and practice.
> In practice, there is.   Yogi Berra
>
> Theory is when you know everything but nothing works.
> Practice is when everything works but no one knows why.
> In our lab, theory and practice are combined:
> nothing works and no one knows why.  ... unknown
>
> --
Mehmet
+1-424-298-1903

Re: questions asked during network engineer interview

[Miles Fidelman]

On 7/14/20 4:14 PM, Matthew Petach wrote:




On Tue, Jul 14, 2020, 11:00 Ahmed elBorno > wrote:


15 years ago, I applied to a network admin role at Google, it was
for their corporate office, not even the production network.

I had less than two years experience.

The interviewer asked me:
[...]
2) If we had a 1GB file that we need to transfer between America
and Europe, how much time do we need, knowing that we start with a
TCP size of X


Well, the first question is the available end-to-end bandwidth. Pretty 
much everything else is irrelevant.


Of course, I might ask them what they mean by "size."

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown

Re: questions asked during network engineer interview

[Michael Thomas]

On 7/14/20 1:25 PM, Miles Fidelman wrote:



- If someone asks me to do an algorithm or coding question, I 
generally tell them to pound sand; that I generally use the language 
statement or a standard library, or look up hard stuff in Knuth - and 
then ask them if they'd like to discuss the specifics about how I 
might approach finding/developing specialized algorithms for the 
problems I'll be working on.  (I refuse to be a code monkey on a 
string - and if they insist, I know that there's no way I'd want to 
work for them.)  I'm reminded of a story an old-line DEC engineer told 
me - at his interview they asked him about converting an octal number 
to hex, or some such - he basically asked if they had an octal-hex 
calculator handy (remember the old paper ones?).  After that, the 
interview went swimmingly - he thought that was kind of a test to see 
how he'd react (who really wants to hire someone who's going to start 
doing paper calculations of something silly).


I got rejected once because he wanted me to write strstr() on a 
whiteboard and it was insufficiently Knuth blessed, which I admitted and 
said in real life I'd just look it up, because you know, that's what 
resourceful engineers do. That wasn't good enough.


Mike, I didn't even know it was programming interview so it took me 
aback even more

Re: questions asked during network engineer interview

[William Herrin]

On Tue, Jul 14, 2020 at 1:26 PM  wrote:
> > William Herrin
> > Sent: Tuesday, July 14, 2020 8:32 PM
> >
> > On Tue, Jul 14, 2020 at 12:17 PM Michael Thomas  wrote:
> > > On 7/14/20 12:09 PM, William Herrin wrote:
> > > > On Mon, Jul 13, 2020 at 3:12 PM Mehmet Akcin 
> > wrote:
> > > >> I am hosting a live show a few times a month about internet
> > > >> infrastructure and today's topics were, your favorite questions
> > > >> asked network engineers - you can watch the recording here
> > > >>
> > > >> https://www.youtube.com/watch?v=o3pvikTrF0M
> > > >>
> > > >> if you have suggestions on topics to cover helping network operations
> > engineering that you want to see in here, please feel free to contact me 
> > off-
> > list, and let's create unique content that can be helpful to others.
> > > >
> > > > "What happens when you type www.google.com in your browser bar
> > and
> > > > hit enter?" is one of my favorite questions. Half the field of
> > > > computing happens next. Keyboard interrupts fire. Bits are poked in
> > > > dram, sram, maybe even tcam. Packets are sent. Fonts are composed
> > into pixels.
> > > > There's a crazy amount you can talk about and the right answer is:
> > > > string things together in order for 5 or 10 minutes without getting
> > > > anything horribly wrong.

> The question is vague enough for the candidate to start talking just about 
> anything they like.
> What happens where? In the world? In the universe? In my body?
> Depending on the position you're hiring for you may want to include the 
> "where" as well to narrow down the scope of the talk (to say "finger tips" if 
> you hire a brain surgeon or 2020 laureate of Kavli Prize for Neuroscience for 
> discover of pressure receptors, or simply to "network" if hiring network 
> engineer, etc...).


You know what job you're interviewing for. What you choose to talk
about tells me volumes about how you think.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: questions asked during network engineer interview

[Michael Thomas]

On 7/14/20 1:23 PM, Scott Weeks wrote:


--- mpet...@netflight.com wrote:
From: Matthew Petach 
On Tue, Jul 14, 2020, 11:00 Ahmed elBorno  wrote:


I had less than two years experience.

The interviewer asked me:
[...]
2) If we had a 1GB file that we need to transfer between America and
Europe, how much time do we need, knowing that we start with a TCP size of
X?



I *love* questions like that, because I can immediately respond back with
"well, that depends; did your sysadmin configure rfc1323 extension support
in your TCP stack?  Is SACK enabled?  What about window scaling?  Does your
OS do dynamic buffer tuning for TCP, or are the values locked in at start
time?"




I'm not so sure someone with only 2 years experience would know that.


On the other hand, it might not be bad ask as a "what would you do if 
somebody asked you this question, what would you do research how to 
answer the question?" because this is definitely something that an 
unknowledgeable person up the management chain might ask.


Mike

Re: questions asked during network engineer interview

[Michael Thomas]

On 7/14/20 1:14 PM, Matthew Petach wrote:



On Tue, Jul 14, 2020, 11:00 Ahmed elBorno > wrote:


15 years ago, I applied to a network admin role at Google, it was
for their corporate office, not even the production network.

I had less than two years experience.

The interviewer asked me:
[...]
2) If we had a 1GB file that we need to transfer between America
and Europe, how much time do we need, knowing that we start with a
TCP size of X?



I *love* questions like that, because I can immediately respond back 
with "well, that depends; did your sysadmin configure rfc1323 
extension support in your TCP stack?  Is SACK enabled?  What about 
window scaling?  Does your OS do dynamic buffer tuning for TCP, or are 
the values locked in at start time?"


Depending on how the interviewer responds gives me a pretty good idea 
how much clue the people I'd be working with have, and how well they 
work collaboratively even with people they don't really know.  If they 
respond well on their feet, and give me better inputs, I respond with 
a better answer.


If they say "It doesn't matter", then I respond by saying "See, that's 
why things aren't working so well for you here; you don't really 
understand how far down the rabbit hole goes", and respectfully ask to 
end the interview before we waste any more of each other's time.


This is the generic problem with interviewing is that people seem to 
believe they are born with a god given innate ability to interview 
people. They ask a generic question, and are surprised and often 
offended that they get an "it depends" and "please clarify XYZ". 
Interviewing is *hard* and doing a semblance of a good interview for a 
candidate is time consuming, so most people just punt with stupid 
unthoughtful questions where they think that all of the requirements are 
perfectly clear. Your answer *should* impress them, but I doubt that's 
the case in general.


Mike

RE: questions asked during network engineer interview

[adamv0025]

> William Herrin
> Sent: Tuesday, July 14, 2020 8:32 PM
> 
> On Tue, Jul 14, 2020 at 12:17 PM Michael Thomas  wrote:
> > On 7/14/20 12:09 PM, William Herrin wrote:
> > > On Mon, Jul 13, 2020 at 3:12 PM Mehmet Akcin 
> wrote:
> > >> I am hosting a live show a few times a month about internet
> > >> infrastructure and today's topics were, your favorite questions
> > >> asked network engineers - you can watch the recording here
> > >>
> > >> https://www.youtube.com/watch?v=o3pvikTrF0M
> > >>
> > >> if you have suggestions on topics to cover helping network operations
> engineering that you want to see in here, please feel free to contact me off-
> list, and let's create unique content that can be helpful to others.
> > >
> > > "What happens when you type www.google.com in your browser bar
> and
> > > hit enter?" is one of my favorite questions. Half the field of
> > > computing happens next. Keyboard interrupts fire. Bits are poked in
> > > dram, sram, maybe even tcam. Packets are sent. Fonts are composed
> into pixels.
> > > There's a crazy amount you can talk about and the right answer is:
> > > string things together in order for 5 or 10 minutes without getting
> > > anything horribly wrong.
> >
> > Oh, I thought this was a trick question of whether it takes you
> > directly to google, or does a search.
> 
> That's a good start. First thing the browser does decide whether that's a URL
> or a search question. How does it decide? And then what happens?
> 
> I will prompt you to keep talking. After all, I'm rooting for you to succeed 
> so
> that I can hire you.
> 
The question is vague enough for the candidate to start talking just about 
anything they like. 
What happens where? In the world? In the universe? In my body?
Depending on the position you're hiring for you may want to include the "where" 
as well to narrow down the scope of the talk (to say "finger tips" if you hire 
a brain surgeon or 2020 laureate of Kavli Prize for Neuroscience for discover 
of pressure receptors, or simply to "network" if hiring network engineer, 
etc...). 
 
adam
 

Re: questions asked during network engineer interview

[Miles Fidelman]

More systems engineer than network engineer - though most of the systems 
I've worked on have been things like network management, and large, 
distributed, networked systems.


Anyway...

I generally ask people:

1. Tell me about yourself:  A good way to find out how someone thinks 
about themself, what interests them, their career path, etc.  (Or it 
tells me that they haven't been paying attention and/or can't present 
themself very well).


2. Tell me a bit more about , or, 
about a piece of work that you're particularly proud of:  Let them tell 
me about something that's significant to them, in depth - ask questions 
that dig into design details, hard challenges, and how they approached & 
solved them.  Maybe get a demo, ask for an architectural overview, then 
deep dive into something interesting.  Maybe also ask them about their 
last all-nighter.


3.  Tell me about how you'd approach getting up to speed and getting 
started on your first project here:  First off, it tells me if they've 
done their homework.  Then, what questions they ask me are rather 
telling.  And then maybe we can get into some white board noodling.  
Ultimately, my main criterion for hiring is if they either poke a hole 
in what we've been doing (AND suggest a solution), or come up with a 
good approach to something that we haven't thought of already.


On the receiving end:

- I make a point of doing my homework about the company, the people I'll 
be interviewing with, the position, and the project. Kind of the way I'd 
approach a consulting gig.


- If someone asks me to do an algorithm or coding question, I generally 
tell them to pound sand; that I generally use the language statement or 
a standard library, or look up hard stuff in Knuth - and then ask them 
if they'd like to discuss the specifics about how I might approach 
finding/developing specialized algorithms for the problems I'll be 
working on.  (I refuse to be a code monkey on a string - and if they 
insist, I know that there's no way I'd want to work for them.)  I'm 
reminded of a story an old-line DEC engineer told me - at his interview 
they asked him about converting an octal number to hex, or some such - 
he basically asked if they had an octal-hex calculator handy (remember 
the old paper ones?).  After that, the interview went swimmingly - he 
thought that was kind of a test to see how he'd react (who really wants 
to hire someone who's going to start doing paper calculations of 
something silly).


Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown

Re: questions asked during network engineer interview

[Scott Weeks]

--- mpet...@netflight.com wrote:
From: Matthew Petach 
On Tue, Jul 14, 2020, 11:00 Ahmed elBorno  wrote:

> I had less than two years experience.
>
> The interviewer asked me:
> [...]
> 2) If we had a 1GB file that we need to transfer between America and
> Europe, how much time do we need, knowing that we start with a TCP size of
> X?
>


I *love* questions like that, because I can immediately respond back with
"well, that depends; did your sysadmin configure rfc1323 extension support
in your TCP stack?  Is SACK enabled?  What about window scaling?  Does your
OS do dynamic buffer tuning for TCP, or are the values locked in at start
time?"




I'm not so sure someone with only 2 years experience would know that.

scott

Re: questions asked during network engineer interview

[Matthew Petach]

On Tue, Jul 14, 2020, 11:00 Ahmed elBorno  wrote:

> 15 years ago, I applied to a network admin role at Google, it was for
> their corporate office, not even the production network.
>
> I had less than two years experience.
>
> The interviewer asked me:
> [...]
> 2) If we had a 1GB file that we need to transfer between America and
> Europe, how much time do we need, knowing that we start with a TCP size of
> X?
>


I *love* questions like that, because I can immediately respond back with
"well, that depends; did your sysadmin configure rfc1323 extension support
in your TCP stack?  Is SACK enabled?  What about window scaling?  Does your
OS do dynamic buffer tuning for TCP, or are the values locked in at start
time?"

Depending on how the interviewer responds gives me a pretty good idea how
much clue the people I'd be working with have, and how well they work
collaboratively even with people they don't really know.  If they respond
well on their feet, and give me better inputs, I respond with a better
answer.

If they say "It doesn't matter", then I respond by saying "See, that's why
things aren't working so well for you here; you don't really understand how
far down the rabbit hole goes", and respectfully ask to end the interview
before we waste any more of each other's time.

I *love* teaching--but only with people who are open to learning.

Stay safe!

Matt



>

Re: questions asked during network engineer interview

[Michael Thomas]

On 7/14/20 12:32 PM, William Herrin wrote:

On Tue, Jul 14, 2020 at 12:17 PM Michael Thomas  wrote:

On 7/14/20 12:09 PM, William Herrin wrote:

On Mon, Jul 13, 2020 at 3:12 PM Mehmet Akcin  wrote:

I am hosting a live show a few times a month about internet infrastructure and 
today's topics were, your favorite questions asked network engineers - you can 
watch the recording here

https://www.youtube.com/watch?v=o3pvikTrF0M

if you have suggestions on topics to cover helping network operations 
engineering that you want to see in here, please feel free to contact me 
off-list, and let's create unique content that can be helpful to others.

"What happens when you type www.google.com in your browser bar and hit
enter?" is one of my favorite questions. Half the field of computing
happens next. Keyboard interrupts fire. Bits are poked in dram, sram,
maybe even tcam. Packets are sent. Fonts are composed into pixels.
There's a crazy amount you can talk about and the right answer is:
string things together in order for 5 or 10 minutes without getting
anything horribly wrong.

Oh, I thought this was a trick question of whether it takes you directly
to google, or does a search.

That's a good start. First thing the browser does decide whether
that's a URL or a search question. How does it decide? And then what
happens?

I will prompt you to keep talking. After all, I'm rooting for you to
succeed so that I can hire you.

Heh. Ok, it has some heuristic which looks for things that appear to be 
a url, or a fragment of a url and if it looks like it's a URL will make 
a canonical representation of url. it's an interesting question whether 
it chooses http or https or both in a happy-eyeballs kind of way and i 
don't know the answer to that. for search, i creates a canonical url to 
google which obeys its query engine's API/parameters.


In both cases, a library routine will be called which knows how to do a 
HTTP(S) GET method which will in turn queries DNS for the host part of 
the url which may use port 53/UPD or the new fangled DoH which I'm 
uncertain whether it runs on plain old 80/443 or something new. Once the 
IP address is fetched, it might literally do Happy Eyeballs to determine 
whether the host is reachable by IPv6 (assuming there was a  record 
for the host), which of course involves connecting a TCP (or now 
QUIC/UDP) socket and performing the three-way handshake to initiate a 
connection, or whatever the QUIC equivalent is since they are trying to 
jam all of the TCP and TLS handshakes into as few exchanges as possible. 
In both cases, a TLS is spun up doing PFS(? I know IPsec does), 
cert-exchange from the server to the client but extremely rarely client 
to server where signatures are created and verified.


I could keep going down the stack but I'll warn you ahead of time that I 
get dodgy at the PHY layer and fancy MAC stuff -- I'm not actually a 
network engineer, so things like VLAN's and 802.1x don't roll off my 
tongue, so you can probably stop this interview now :)


Mike

Re: questions asked during network engineer interview

[William Herrin]

On Mon, Jul 13, 2020 at 3:12 PM Mehmet Akcin  wrote:
> if you have suggestions on topics to cover helping network operations 
> engineering that you want to see in here, please feel free to contact me 
> off-list, and let's create unique content that can be helpful to others.

I'm also a fan of Amazon's STAR approach: Situation, Task, Activity,
Result. They didn't invent it but they're really good at it. STAR is
where you ask the candidate to tell you about some situation they
encountered in their work, what they did, and how it turned out
(including what they learned and would do differently). It's open
ended and bias-neutral. Which is a big deal.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

RE: questions asked during network engineer interview

[adamv0025]

This is exactly why the espresso network looks like it does… 

Have you seen the advert for network architect position at google? Bunch of 
programming languages and that’s enough apparently.

adam

 

From: NANOG  On Behalf Of 
Ahmed elBorno
Sent: Tuesday, July 14, 2020 6:57 PM
To: Michael Thomas 
Cc: NANOG list 
Subject: Re: questions asked during network engineer interview

 

15 years ago, I applied to a network admin role at Google, it was for their 
corporate office, not even the production network.

 

I had less than two years experience.

 

The interviewer asked me:

 

1) What is the difference between flow balancing techniques on Cisco IOS and 
Linux?

2) If we had a 1GB file that we need to transfer between America and Europe, 
how much time do we need, knowing that we start with a TCP size of X?

 

I'll never forget this :)

 

On Tue, Jul 14, 2020 at 10:50 AM Michael Thomas mailto:m...@mtcc.com> > wrote:

 

On 7/14/20 10:33 AM, Owen DeLong wrote:

On Jul 14, 2020, at 10:20 , Michael Thomas mailto:m...@mtcc.com> > wrote:





I once failed a network engineering interview because I couldn’t recite the 
OSPF LSA types by number from memory. It was fine, the fact that was a key 
question in the interview convinced me that I had no more desire to work there 
than they had to hire me.

I once got rejected because I spaced out and didn't remember the java keyword 
"final" as a constant. you can't make this stuff up.

 

My personal method is to devise a problem and actually work with them... 
because that's what I (or others) are going to be doing. How well can they get 
the requirements? How do they zero in on how to solve it? You can take this as 
deep or shallow as you like. Often I'd give it as a homework assignment if I 
liked them.

I prefer this approach as well. Depending on the level of interviewee, I like 
to pull up a real world scenario from my past and see how they approach it. I’m 
not nearly as concerned if they get to the right solution as I want to see how 
they go about identifying and solving the problem. Do they ask questions that 
narrow their focus and identify the issue, or do they start trying random 
things hoping to stumble across a solution without understanding the problem?

I often use something that was somewhat topical to me but dumbed down enough to 
fit in an interview and possible homework assignment. My reasoning is that I'm 
not entirely sure what the solution ought to look like either, so I'm 
interested to see what their take is. I can also give them real time feedback 
just like I would if they were a co-worker. At base, an interview should answer 
the question: "can I work with this person?". 




Not being a developer (at least not for the last 25+ years), I haven’t done 
many “software” interviews, but I’ve been through network and sysadmin 
interviews that ran the gamut. Frankly, the ones that seemed to be more about 
fluffing privates were the companies I put less focus on going forward. The 
interviewers that seemed to match my style and wanted to see me do real-world 
things like troubleshooting or solving design problems or identifying 
architectural flaws in a proposed solution usually resulted in mutual respect 
and I usually moved forward through the interview processes. On the few 
occasions where I got a job out of a fluffing interview, it almost universally 
turned out to be one I wished I hadn’t taken.

I had a screening interview at Google where the screener asked some ridiculous 
question that nobody not straight out of school would know, and even then not 
likely. I was like, wtf? If that's how they treat candidates -- and from 
everything I've heard it is -- I want nothing to do with them, and flat out 
refused their recruiters a dozen time afterward even though they pleaded that 
they've changed. Sorry, interviewing is a two-way street.

Mike

Re: questions asked during network engineer interview

[William Herrin]

On Tue, Jul 14, 2020 at 10:59 AM Ahmed elBorno  wrote:
>
> 15 years ago, I applied to a network admin role at Google, it was for their 
> corporate office, not even the production network.
>
> I had less than two years experience.
>
> The interviewer asked me:
>
> 1) What is the difference between flow balancing techniques on Cisco IOS and 
> Linux?
> 2) If we had a 1GB file that we need to transfer between America and Europe, 
> how much time do we need, knowing that we start with a TCP size of X?

Hi Ahmed,

Those are terrible questions. I've been in the business for a quarter
century, a Linux and Cisco IOS user for most of that and I don't, off
hand, know the answer to #1. As for number #2, it's highly variable
depending on when you lose the first packet, ending fast window
growth. And you will. On a gigabyte transfer over any real-world
network, you will lose some packets both to congestion and bit errors.
And that's before you consider the long-fat-pipe problem. Trying to
treat it like a math train problem is bizarre.

My Google interviewers asked much better questions, along the lines of
"build me this" or "debug this problem." Even then they fell in to one
of the traps with that methodology: on the "debug this problem"
question, the interviewer wasn't familiar with one of the diagnostic
commands I went to, so he guessed at what the output would be. His
guess was just enough wrong to eliminate the cause he wanted me to
find. The command should have hung accessing a faulty NFS mount but in
his version of the story it didn't.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: questions asked during network engineer interview

[William Herrin]

On Tue, Jul 14, 2020 at 12:17 PM Michael Thomas  wrote:
> On 7/14/20 12:09 PM, William Herrin wrote:
> > On Mon, Jul 13, 2020 at 3:12 PM Mehmet Akcin  wrote:
> >> I am hosting a live show a few times a month about internet infrastructure 
> >> and today's topics were, your favorite questions asked network engineers - 
> >> you can watch the recording here
> >>
> >> https://www.youtube.com/watch?v=o3pvikTrF0M
> >>
> >> if you have suggestions on topics to cover helping network operations 
> >> engineering that you want to see in here, please feel free to contact me 
> >> off-list, and let's create unique content that can be helpful to others.
> >
> > "What happens when you type www.google.com in your browser bar and hit
> > enter?" is one of my favorite questions. Half the field of computing
> > happens next. Keyboard interrupts fire. Bits are poked in dram, sram,
> > maybe even tcam. Packets are sent. Fonts are composed into pixels.
> > There's a crazy amount you can talk about and the right answer is:
> > string things together in order for 5 or 10 minutes without getting
> > anything horribly wrong.
>
> Oh, I thought this was a trick question of whether it takes you directly
> to google, or does a search.

That's a good start. First thing the browser does decide whether
that's a URL or a search question. How does it decide? And then what
happens?

I will prompt you to keep talking. After all, I'm rooting for you to
succeed so that I can hire you.

-Bill



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: questions asked during network engineer interview

[Michael Thomas]

On 7/14/20 12:09 PM, William Herrin wrote:

On Mon, Jul 13, 2020 at 3:12 PM Mehmet Akcin  wrote:

I am hosting a live show a few times a month about internet infrastructure and 
today's topics were, your favorite questions asked network engineers - you can 
watch the recording here

https://www.youtube.com/watch?v=o3pvikTrF0M

if you have suggestions on topics to cover helping network operations 
engineering that you want to see in here, please feel free to contact me 
off-list, and let's create unique content that can be helpful to others.


"What happens when you type www.google.com in your browser bar and hit
enter?" is one of my favorite questions. Half the field of computing
happens next. Keyboard interrupts fire. Bits are poked in dram, sram,
maybe even tcam. Packets are sent. Fonts are composed into pixels.
There's a crazy amount you can talk about and the right answer is:
string things together in order for 5 or 10 minutes without getting
anything horribly wrong.


Oh, I thought this was a trick question of whether it takes you directly 
to google, or does a search.


Mike, i failed that interview i guess

Re: questions asked during network engineer interview

[William Herrin]

On Mon, Jul 13, 2020 at 3:12 PM Mehmet Akcin  wrote:
> I am hosting a live show a few times a month about internet infrastructure 
> and today's topics were, your favorite questions asked network engineers - 
> you can watch the recording here
>
> https://www.youtube.com/watch?v=o3pvikTrF0M
>
> if you have suggestions on topics to cover helping network operations 
> engineering that you want to see in here, please feel free to contact me 
> off-list, and let's create unique content that can be helpful to others.


"What happens when you type www.google.com in your browser bar and hit
enter?" is one of my favorite questions. Half the field of computing
happens next. Keyboard interrupts fire. Bits are poked in dram, sram,
maybe even tcam. Packets are sent. Fonts are composed into pixels.
There's a crazy amount you can talk about and the right answer is:
string things together in order for 5 or 10 minutes without getting
anything horribly wrong.

And the best parts:

With the choices they make, they'll tell you exactly how deep their
knowledge goes. So it works for all tech hires, junior to senior,
sysadmin, developer, network engineer, whatever.

It's an oral question, you don't have to write or draw anything to
answer, so you can use it in a phone screen.

Regards,
Bill Herrin


--
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: questions asked during network engineer interview

[Michael Thomas]

On 7/14/20 11:19 AM, Peter Kristolaitis wrote:

On 2020-07-14 1:55 p.m., Michael Thomas wrote:
But I try as much as possible to put candidates at ease because I 
know that not everybody reacts to interviews the same, which is sadly 
not the case far too often.


Mike

I often ask a question early in the interview to the effect of "Tell 
me about a tech project you've worked on outside of your professional 
work.  It doesn't have to be related at all to this role or any other 
professional role you've worked on, just something cool involving tech 
that you've done on your own time."


I don't care if the answer is setting up a complicated home lab, or 
programming Arduinos to make a robotic cat feeder, or 3D printing, or 
whatever.   I ask this question for two reasons: first, there is a 
correlation between being passionate about technology and being good 
at working with it and learning it professionally;  and second, 
talking about not-directly-related-to-the-resume stuff for a couple of 
minutes often lets the "introvert geek" personality-types relax and 
open up a lot.  I find this is particularly helpful when hiring for 
junior and intermediate roles, but I will sometimes ask it of senior 
candidates too.




Oh, I like that one too and ask it often. It's sort of depressing how 
often the answer is "i don't have time" or something to that effect.


I wrote a LIGO listener to monitor the cosmic kabooms as they were 
detected just for fun and to learn Django. You have to be constantly 
refreshing your skills and that habit is way more important than whether 
you can code up algorithm XYZ or tell me how TCP slow start works.


Mike

Re: questions asked during network engineer interview

[Peter Kristolaitis]

On 2020-07-14 1:55 p.m., Michael Thomas wrote:
But I try as much as possible to put candidates at ease because I know 
that not everybody reacts to interviews the same, which is sadly not 
the case far too often.


Mike

I often ask a question early in the interview to the effect of "Tell me 
about a tech project you've worked on outside of your professional 
work.  It doesn't have to be related at all to this role or any other 
professional role you've worked on, just something cool involving tech 
that you've done on your own time."


I don't care if the answer is setting up a complicated home lab, or 
programming Arduinos to make a robotic cat feeder, or 3D printing, or 
whatever.   I ask this question for two reasons: first, there is a 
correlation between being passionate about technology and being good at 
working with it and learning it professionally;  and second, talking 
about not-directly-related-to-the-resume stuff for a couple of minutes 
often lets the "introvert geek" personality-types relax and open up a 
lot.  I find this is particularly helpful when hiring for junior and 
intermediate roles, but I will sometimes ask it of senior candidates too.

Re: questions asked during network engineer interview

[Ahmed elBorno]

15 years ago, I applied to a network admin role at Google, it was for their
corporate office, not even the production network.

I had less than two years experience.

The interviewer asked me:

1) What is the difference between flow balancing techniques on Cisco IOS
and Linux?
2) If we had a 1GB file that we need to transfer between America and
Europe, how much time do we need, knowing that we start with a TCP size of
X?

I'll never forget this :)

On Tue, Jul 14, 2020 at 10:50 AM Michael Thomas  wrote:

>
> On 7/14/20 10:33 AM, Owen DeLong wrote:
>
> On Jul 14, 2020, at 10:20 , Michael Thomas  wrote:
>
>
> I once failed a network engineering interview because I couldn’t recite
> the OSPF LSA types by number from memory. It was fine, the fact that was a
> key question in the interview convinced me that I had no more desire to
> work there than they had to hire me.
>
> I once got rejected because I spaced out and didn't remember the java
> keyword "final" as a constant. you can't make this stuff up.
>
>
> My personal method is to devise a problem and actually work with them...
> because that's what I (or others) are going to be doing. How well can they
> get the requirements? How do they zero in on how to solve it? You can take
> this as deep or shallow as you like. Often I'd give it as a homework
> assignment if I liked them.
>
> I prefer this approach as well. Depending on the level of interviewee, I
> like to pull up a real world scenario from my past and see how they
> approach it. I’m not nearly as concerned if they get to the right solution
> as I want to see how they go about identifying and solving the problem. Do
> they ask questions that narrow their focus and identify the issue, or do
> they start trying random things hoping to stumble across a solution without
> understanding the problem?
>
> I often use something that was somewhat topical to me but dumbed down
> enough to fit in an interview and possible homework assignment. My
> reasoning is that I'm not entirely sure what the solution ought to look
> like either, so I'm interested to see what their take is. I can also give
> them real time feedback just like I would if they were a co-worker. At
> base, an interview should answer the question: "can I work with this
> person?".
>
> Not being a developer (at least not for the last 25+ years), I haven’t
> done many “software” interviews, but I’ve been through network and sysadmin
> interviews that ran the gamut. Frankly, the ones that seemed to be more
> about fluffing privates were the companies I put less focus on going
> forward. The interviewers that seemed to match my style and wanted to see
> me do real-world things like troubleshooting or solving design problems or
> identifying architectural flaws in a proposed solution usually resulted in
> mutual respect and I usually moved forward through the interview processes.
> On the few occasions where I got a job out of a fluffing interview, it
> almost universally turned out to be one I wished I hadn’t taken.
>
> I had a screening interview at Google where the screener asked some
> ridiculous question that nobody not straight out of school would know, and
> even then not likely. I was like, wtf? If that's how they treat candidates
> -- and from everything I've heard it is -- I want nothing to do with them,
> and flat out refused their recruiters a dozen time afterward even though
> they pleaded that they've changed. Sorry, interviewing is a two-way street.
>
> Mike
>

Re: questions asked during network engineer interview

[Michael Thomas]

On 7/14/20 10:46 AM, Shawn L via NANOG wrote:


I completely agree.  One of the people I used to do interviews with 
would look through the resume, etc. and then say something like "this 
all looks good. Tell me about something you've done".  And we'd move 
on to talk about projects and how they tackled it, etc.


We didn't give tests, just questions like  "if we asked you to do 
this, on something you haven't seen or used before, how would you go 
about it".   Or pretend I'm the customer.  I want to do this.  How 
would you go about it?  it wasn't about getting a 'correct' answer, it 
was about how they went about solving the problem.




I do that too. I figure that if they can't teach me about something 
they've done in real life, they're probably overstating their 
involvement. People should *like* talking about how they went about 
solving problems and be proud of what they achieved. But I try as much 
as possible to put candidates at ease because I know that not everybody 
reacts to interviews the same, which is sadly not the case far too often.


Mike

Re: questions asked during network engineer interview

[Michael Thomas]

On 7/14/20 10:33 AM, Owen DeLong wrote:
On Jul 14, 2020, at 10:20 , Michael Thomas > wrote:


I once failed a network engineering interview because I couldn’t 
recite the OSPF LSA types by number from memory. It was fine, the 
fact that was a key question in the interview convinced me that I had 
no more desire to work there than they had to hire me.


I once got rejected because I spaced out and didn't remember the java 
keyword "final" as a constant. you can't make this stuff up.



My personal method is to devise a problem and actually work with 
them... because that's what I (or others) are going to be doing. How 
well can they get the requirements? How do they zero in on how to 
solve it? You can take this as deep or shallow as you like. Often I'd 
give it as a homework assignment if I liked them.


I prefer this approach as well. Depending on the level of interviewee, 
I like to pull up a real world scenario from my past and see how they 
approach it. I’m not nearly as concerned if they get to the right 
solution as I want to see how they go about identifying and solving 
the problem. Do they ask questions that narrow their focus and 
identify the issue, or do they start trying random things hoping to 
stumble across a solution without understanding the problem?
I often use something that was somewhat topical to me but dumbed down 
enough to fit in an interview and possible homework assignment. My 
reasoning is that I'm not entirely sure what the solution ought to look 
like either, so I'm interested to see what their take is. I can also 
give them real time feedback just like I would if they were a co-worker. 
At base, an interview should answer the question: "can I work with this 
person?".


Not being a developer (at least not for the last 25+ years), I haven’t 
done many “software” interviews, but I’ve been through network and 
sysadmin interviews that ran the gamut. Frankly, the ones that seemed 
to be more about fluffing privates were the companies I put less focus 
on going forward. The interviewers that seemed to match my style and 
wanted to see me do real-world things like troubleshooting or solving 
design problems or identifying architectural flaws in a proposed 
solution usually resulted in mutual respect and I usually moved 
forward through the interview processes. On the few occasions where I 
got a job out of a fluffing interview, it almost universally turned 
out to be one I wished I hadn’t taken.


I had a screening interview at Google where the screener asked some 
ridiculous question that nobody not straight out of school would know, 
and even then not likely. I was like, wtf? If that's how they treat 
candidates -- and from everything I've heard it is -- I want nothing to 
do with them, and flat out refused their recruiters a dozen time 
afterward even though they pleaded that they've changed. Sorry, 
interviewing is a two-way street.


Mike

Re: questions asked during network engineer interview

[Shawn L via NANOG]

I completely agree.  One of the people I used to do interviews with would look 
through the resume, etc. and then say something like "this all looks good. Tell 
me about something you've done".  And we'd move on to talk about projects and 
how they tackled it, etc. 
 
We didn't give tests, just questions like  "if we asked you to do this, on 
something you haven't seen or used before, how would you go about it".   Or 
pretend I'm the customer.  I want to do this.  How would you go about it?  it 
wasn't about getting a 'correct' answer, it was about how they went about 
solving the problem.

-Original Message-
From: "Owen DeLong" 
Sent: Tuesday, July 14, 2020 1:33pm
To: "Michael Thomas" 
Cc: nanog@nanog.org
Subject: Re: questions asked during network engineer interview




On Jul 14, 2020, at 10:20 , Michael Thomas <[ m...@mtcc.com ]( 
mailto:m...@mtcc.com )> wrote:


 
On 7/13/20 8:16 PM, Greg Skinner via NANOG wrote:If you ever decide to revisit 
this subject, I recall it was covered here in [ this thread started by Bill 
Herrin ]( https://mailman.nanog.org/pipermail/nanog/2012-July/149687.html ).
My general feelings on the subject of tech interviews are summarized in the 
“interview anti-loop” section of [ this article by Steve Yegge ]( 
http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html ).   
Although it is targeted to people seeking software engineering jobs at FANG 
(and FANG-like) companies, IMO the general tone is applicable to other tech 
careers, even network engineering.  I have seen numerous articles (and 
subsequent discussions) on this subject on forums such as Quora, Medium, and 
Hacker News.
 
That blog post is everything that is wrong with software interviews. It's fine 
to ask intricate algorithm questions for somebody fresh out of school because 
what else are you going to ask them? But for somebody who's years out of school 
and has lots of experience, the intricate details of various algorithms fade 
especially ones that you don't use very often, or are embedded in library 
routines you'd be fired for if you tried to reinvent them. Telling people they 
have to go back to school for stuff they won't be using on the job is 
offensive.I once failed a network engineering interview because I couldn’t 
recite the OSPF LSA types by number from memory. It was fine, the fact that was 
a key question in the interview convinced me that I had no more desire to work 
there than they had to hire me.



My personal method is to devise a problem and actually work with them... 
because that's what I (or others) are going to be doing. How well can they get 
the requirements? How do they zero in on how to solve it? You can take this as 
deep or shallow as you like. Often I'd give it as a homework assignment if I 
liked them.I prefer this approach as well. Depending on the level of 
interviewee, I like to pull up a real world scenario from my past and see how 
they approach it. I’m not nearly as concerned if they get to the right solution 
as I want to see how they go about identifying and solving the problem. Do they 
ask questions that narrow their focus and identify the issue, or do they start 
trying random things hoping to stumble across a solution without understanding 
the problem?
The former moves on to the next steps towards employment. The latter is dropped 
from consideration.



My personal theory is software interviewing is basically a hazing ritual where 
the interviewers are trying to fluff their own privates, and it's almost to a 
one male. I wrote this post a while ago:
[ http://rip-van-webble.blogspot.com/2013/07/interviews-as-hazing-rituals.html 
]( http://rip-van-webble.blogspot.com/2013/07/interviews-as-hazing-rituals.html 
)
MikeNot being a developer (at least not for the last 25+ years), I haven’t done 
many “software” interviews, but I’ve been through network and sysadmin 
interviews that ran the gamut. Frankly, the ones that seemed to be more about 
fluffing privates were the companies I put less focus on going forward. The 
interviewers that seemed to match my style and wanted to see me do real-world 
things like troubleshooting or solving design problems or identifying 
architectural flaws in a proposed solution usually resulted in mutual respect 
and I usually moved forward through the interview processes. On the few 
occasions where I got a job out of a fluffing interview, it almost universally 
turned out to be one I wished I hadn’t taken.
Owen

Re: questions asked during network engineer interview

[Owen DeLong]

> On Jul 14, 2020, at 10:20 , Michael Thomas  wrote:
> 
> 
> 
> On 7/13/20 8:16 PM, Greg Skinner via NANOG wrote:
>> If you ever decide to revisit this subject, I recall it was covered here in 
>> this thread started by Bill Herrin 
>> .
>> 
>> My general feelings on the subject of tech interviews are summarized in the 
>> “interview anti-loop” section of this article by Steve Yegge 
>> .   
>> Although it is targeted to people seeking software engineering jobs at FANG 
>> (and FANG-like) companies, IMO the general tone is applicable to other tech 
>> careers, even network engineering.  I have seen numerous articles (and 
>> subsequent discussions) on this subject on forums such as Quora, Medium, and 
>> Hacker News.
> 
> That blog post is everything that is wrong with software interviews. It's 
> fine to ask intricate algorithm questions for somebody fresh out of school 
> because what else are you going to ask them? But for somebody who's years out 
> of school and has lots of experience, the intricate details of various 
> algorithms fade especially ones that you don't use very often, or are 
> embedded in library routines you'd be fired for if you tried to reinvent 
> them. Telling people they have to go back to school for stuff they won't be 
> using on the job is offensive.
> 

I once failed a network engineering interview because I couldn’t recite the 
OSPF LSA types by number from memory. It was fine, the fact that was a key 
question in the interview convinced me that I had no more desire to work there 
than they had to hire me.
> My personal method is to devise a problem and actually work with them... 
> because that's what I (or others) are going to be doing. How well can they 
> get the requirements? How do they zero in on how to solve it? You can take 
> this as deep or shallow as you like. Often I'd give it as a homework 
> assignment if I liked them.
> 
I prefer this approach as well. Depending on the level of interviewee, I like 
to pull up a real world scenario from my past and see how they approach it. I’m 
not nearly as concerned if they get to the right solution as I want to see how 
they go about identifying and solving the problem. Do they ask questions that 
narrow their focus and identify the issue, or do they start trying random 
things hoping to stumble across a solution without understanding the problem?

The former moves on to the next steps towards employment. The latter is dropped 
from consideration.
> My personal theory is software interviewing is basically a hazing ritual 
> where the interviewers are trying to fluff their own privates, and it's 
> almost to a one male. I wrote this post a while ago:
> 
> http://rip-van-webble.blogspot.com/2013/07/interviews-as-hazing-rituals.html 
> 
> Mike
> 

Not being a developer (at least not for the last 25+ years), I haven’t done 
many “software” interviews, but I’ve been through network and sysadmin 
interviews that ran the gamut. Frankly, the ones that seemed to be more about 
fluffing privates were the companies I put less focus on going forward. The 
interviewers that seemed to match my style and wanted to see me do real-world 
things like troubleshooting or solving design problems or identifying 
architectural flaws in a proposed solution usually resulted in mutual respect 
and I usually moved forward through the interview processes. On the few 
occasions where I got a job out of a fluffing interview, it almost universally 
turned out to be one I wished I hadn’t taken.

Owen

Re: questions asked during network engineer interview

[Michael Thomas]

On 7/13/20 8:16 PM, Greg Skinner via NANOG wrote:
If you ever decide to revisit this subject, I recall it was covered 
here in this thread started by Bill Herrin 
.


My general feelings on the subject of tech interviews are summarized 
in the “interview anti-loop” section of this article by Steve Yegge 
. 
 Although it is targeted to people seeking software engineering jobs 
at FANG (and FANG-like) companies, IMO the general tone is applicable 
to other tech careers, even network engineering.  I have seen numerous 
articles (and subsequent discussions) on this subject on forums such 
as Quora, Medium, and Hacker News.



That blog post is everything that is wrong with software interviews. 
It's fine to ask intricate algorithm questions for somebody fresh out of 
school because what else are you going to ask them? But for somebody 
who's years out of school and has lots of experience, the intricate 
details of various algorithms fade especially ones that you don't use 
very often, or are embedded in library routines you'd be fired for if 
you tried to reinvent them. Telling people they have to go back to 
school for stuff they won't be using on the job is offensive.


My personal method is to devise a problem and actually work with them... 
because that's what I (or others) are going to be doing. How well can 
they get the requirements? How do they zero in on how to solve it? You 
can take this as deep or shallow as you like. Often I'd give it as a 
homework assignment if I liked them.


My personal theory is software interviewing is basically a hazing ritual 
where the interviewers are trying to fluff their own privates, and it's 
almost to a one male. I wrote this post a while ago:


http://rip-van-webble.blogspot.com/2013/07/interviews-as-hazing-rituals.html

Mike




—gregbo

On Jul 11, 2020, at 11:34 AM, Mehmet Akcin > wrote:


hey there,

I am hosting a live show a few times a month about internet 
infrastructure
and today's topics were, your favorite questions asked network 
engineers -

you can watch the recording here

https://www.youtube.com/watch?v=o3pvikTrF0M

if you have suggestions on topics to cover helping network operations
engineering that you want to see in here, please feel free to contact me
off-list, and let's create unique content that can be helpful to others.

mehmet
-- next part --
An HTML attachment was scrubbed...
URL: 

Re: questions asked during network engineer interview

[Greg Skinner via NANOG]

If you ever decide to revisit this subject, I recall it was covered here in 
this thread started by Bill Herrin 
.

My general feelings on the subject of tech interviews are summarized in the 
“interview anti-loop” section of this article by Steve Yegge 
.   
Although it is targeted to people seeking software engineering jobs at FANG 
(and FANG-like) companies, IMO the general tone is applicable to other tech 
careers, even network engineering.  I have seen numerous articles (and 
subsequent discussions) on this subject on forums such as Quora, Medium, and 
Hacker News.

—gregbo

> On Jul 11, 2020, at 11:34 AM, Mehmet Akcin  wrote:
> 
> hey there,
> 
> I am hosting a live show a few times a month about internet infrastructure
> and today's topics were, your favorite questions asked network engineers -
> you can watch the recording here
> 
> https://www.youtube.com/watch?v=o3pvikTrF0M
> 
> if you have suggestions on topics to cover helping network operations
> engineering that you want to see in here, please feel free to contact me
> off-list, and let's create unique content that can be helpful to others.
> 
> mehmet
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> 
>