questions asked during network engineer interview
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
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. —gregbo
On Jul 11, 2020, at 11:34 AM, Mehmet Akcin <mehmet@akcin.net> 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
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. 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 <mehmet@akcin.net <mailto:mehmet@akcin.net>> 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
On Jul 14, 2020, at 10:20 , Michael Thomas <mike@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> 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
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" <owen@delong.com> Sent: Tuesday, July 14, 2020 1:33pm To: "Michael Thomas" <mike@mtcc.com> Cc: nanog@nanog.org Subject: Re: questions asked during network engineer interview On Jul 14, 2020, at 10:20 , Michael Thomas <[ mike@mtcc.com ]( mailto:mike@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
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
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.
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
On 7/14/20 10:33 AM, Owen DeLong wrote:
On Jul 14, 2020, at 10:20 , Michael Thomas <mike@mtcc.com <mailto:mike@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.
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
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. 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
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 <mike@mtcc.com> wrote:
On 7/14/20 10:33 AM, Owen DeLong wrote:
On Jul 14, 2020, at 10:20 , Michael Thomas <mike@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
On Tue, Jul 14, 2020 at 10:59 AM Ahmed elBorno <amaged@gmail.com> 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 bill@herrin.us https://bill.herrin.us/
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 <a project listed on their resume>, 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
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
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 <nanog-bounces+adamv0025=netconsultings.com@nanog.org> On Behalf Of Ahmed elBorno Sent: Tuesday, July 14, 2020 6:57 PM To: Michael Thomas <mike@mtcc.com> Cc: NANOG list <nanog@nanog.org> 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 <mike@mtcc.com <mailto:mike@mtcc.com> > wrote: On 7/14/20 10:33 AM, Owen DeLong wrote: On Jul 14, 2020, at 10:20 , Michael Thomas <mike@mtcc.com <mailto:mike@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
On Tue, Jul 14, 2020, 11:00 Ahmed elBorno <amaged@gmail.com> 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
On 7/14/20 1:14 PM, Matthew Petach wrote:
On Tue, Jul 14, 2020, 11:00 Ahmed elBorno <amaged@gmail.com <mailto:amaged@gmail.com>> 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
On 7/14/20 4:14 PM, Matthew Petach wrote:
On Tue, Jul 14, 2020, 11:00 Ahmed elBorno <amaged@gmail.com <mailto:amaged@gmail.com>> 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
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 <mfidelman@meetinghouse.net> wrote:
On 7/14/20 4:14 PM, Matthew Petach wrote:
On Tue, Jul 14, 2020, 11:00 Ahmed elBorno <amaged@gmail.com> 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
----- On Jul 14, 2020, at 1:14 PM, Matthew Petach <mpetach@netflight.com> 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
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.
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
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 <owen@delong.com> wrote:
On Jul 14, 2020, at 10:20 , Michael Thomas <mike@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.
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
Comments inline.
On Jul 14, 2020, at 3:35 PM, Andrey Khomyakov <khomyakov.andrey@gmail.com> 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 <http://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
On Mon, Jul 13, 2020 at 3:12 PM Mehmet Akcin <mehmet@akcin.net> 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 bill@herrin.us https://bill.herrin.us/
On 7/14/20 12:09 PM, William Herrin wrote:
On Mon, Jul 13, 2020 at 3:12 PM Mehmet Akcin <mehmet@akcin.net> 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
On Tue, Jul 14, 2020 at 12:17 PM Michael Thomas <mike@mtcc.com> wrote:
On 7/14/20 12:09 PM, William Herrin wrote:
On Mon, Jul 13, 2020 at 3:12 PM Mehmet Akcin <mehmet@akcin.net> 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 bill@herrin.us https://bill.herrin.us/
On 7/14/20 12:32 PM, William Herrin wrote:
On 7/14/20 12:09 PM, William Herrin wrote:
On Mon, Jul 13, 2020 at 3:12 PM Mehmet Akcin <mehmet@akcin.net> 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
On Tue, Jul 14, 2020 at 12:17 PM Michael Thomas <mike@mtcc.com> wrote: 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 AAAA 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
William Herrin Sent: Tuesday, July 14, 2020 8:32 PM
On 7/14/20 12:09 PM, William Herrin wrote:
On Mon, Jul 13, 2020 at 3:12 PM Mehmet Akcin <mehmet@akcin.net> 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-
On Tue, Jul 14, 2020 at 12:17 PM Michael Thomas <mike@mtcc.com> wrote: 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
On Tue, Jul 14, 2020 at 1:26 PM <adamv0025@netconsultings.com> wrote:
William Herrin Sent: Tuesday, July 14, 2020 8:32 PM
On 7/14/20 12:09 PM, William Herrin wrote:
On Mon, Jul 13, 2020 at 3:12 PM Mehmet Akcin <mehmet@akcin.net> 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-
On Tue, Jul 14, 2020 at 12:17 PM Michael Thomas <mike@mtcc.com> wrote: 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 bill@herrin.us https://bill.herrin.us/
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.
On Mon, Jul 20, 2020 at 5:09 AM Mark Tinka <mark.tinka@seacom.com> 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 bill@herrin.us https://bill.herrin.us/
On 7/20/20 1:02 PM, William Herrin 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
On Mon, Jul 20, 2020 at 5:09 AM Mark Tinka <mark.tinka@seacom.com> wrote: 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
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
On Mon, Jul 20, 2020 at 4:45 PM Sander Steffann <sander@steffann.nl> 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
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
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.
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 ben@6by7.net <mailto:ben@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 <mark.tinka@seacom.com> 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.
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 <mark.tinka@seacom.com> 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.
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.
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 <mark.tinka@seacom.com<mailto:mark.tinka@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.
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.
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 <mark.tinka@seacom.com> 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.
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.
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
On 21/Jul/20 18:39, adamv0025@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.
From: Mark Tinka <mark.tinka@seacom.com> Sent: Tuesday, July 21, 2020 6:14 PM
On 21/Jul/20 18:39, adamv0025@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
On 21/Jul/20 19:26, adamv0025@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.
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, "adamv0025@netconsultings.com" <adamv0025@netconsultings.com> wrote:
From: Mark Tinka <mark.tinka@seacom.com> Sent: Tuesday, July 21, 2020 6:14 PM
On 21/Jul/20 18:39, adamv0025@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
From: Mel Beckman <mel@beckman.org> 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
Adam,
On 21 Jul 2020, at 19:13, Mark Tinka <mark.tinka@seacom.com> wrote: On 21/Jul/20 18:39, adamv0025@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&S/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
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
----- On Jul 22, 2020, at 4:04 PM, Brandon Martin lists.nanog@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
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.
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
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 <adamv0025@netconsultings.com> 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
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 <Michael.Douglas@ieee.org> 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 <adamv0025@netconsultings.com> 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
----- On Jul 23, 2020, at 6:31 AM, Michael Douglas <Michael.Douglas@ieee.org> 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
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 <sabri@cluecentral.net> wrote: ----- On Jul 23, 2020, at 6:31 AM, Michael Douglas <Michael.Douglas@ieee.org> 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
On Thu, Jul 23, 2020 at 6:33 AM Michael Douglas <Michael.Douglas@ieee.org> 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 bill@herrin.us https://bill.herrin.us/
On 7/23/20 3:26 PM, William Herrin 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
On Thu, Jul 23, 2020 at 6:33 AM Michael Douglas <Michael.Douglas@ieee.org> wrote: 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
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.
On Fri, Jul 24, 2020 at 12:08 AM Mark Tinka <mark.tinka@seacom.com> 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 bill@herrin.us https://bill.herrin.us/
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.
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 web@typo.org Network Dude http://www.typo.org/~web/
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.
On Fri, Jul 24, 2020 at 12:44 AM Mark Tinka <mark.tinka@seacom.com> 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 bill@herrin.us https://bill.herrin.us/
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.
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.
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.
On Thu, 23 Jul 2020 10:03:15 +0100, adamv0025@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. :)
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.
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
On Mon, Jul 20, 2020 at 9:57 PM Mark Tinka <mark.tinka@seacom.com> 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 bill@herrin.us https://bill.herrin.us/
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
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 <nick@foobar.org> 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
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.
On Jul 21, 2020, at 2:58 PM, Mark Tinka <mark.tinka@seacom.com> 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
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.
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 <bill@herrin.us> wrote:
On Mon, Jul 20, 2020 at 9:57 PM Mark Tinka <mark.tinka@seacom.com> 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 bill@herrin.us https://bill.herrin.us/
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. :)
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.
On Tue, Jul 21, 2020 at 2:55 PM Mark Tinka <mark.tinka@seacom.com> 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 bill@herrin.us https://bill.herrin.us/
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.
On Wed, Jul 22, 2020 at 12:41 AM Mark Tinka <mark.tinka@seacom.com> 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 bill@herrin.us https://bill.herrin.us/
William Herrin Sent: Tuesday, July 21, 2020 8:21 PM
On Mon, Jul 20, 2020 at 9:57 PM Mark Tinka <mark.tinka@seacom.com> 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&T 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
William Herrin Sent: Monday, July 20, 2020 9:02 PM
On Mon, Jul 20, 2020 at 5:09 AM Mark Tinka <mark.tinka@seacom.com> 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. <sigh>technology used to be much simpler. adam
On Tue, Jul 21, 2020 at 9:50 AM <adamv0025@netconsultings.com> 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 bill@herrin.us https://bill.herrin.us/
On Mon, Jul 13, 2020 at 3:12 PM Mehmet Akcin <mehmet@akcin.net> 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 bill@herrin.us https://bill.herrin.us/
participants (28)
-
adamv0025＠netconsultings.com -
Ahmed elBorno -
Andrey Khomyakov -
Ben Cannon -
Brandon Martin -
Greg Skinner -
Here At InfoChambers -
Joe Hamelin -
Mark Tinka -
Matthew Petach -
Mehmet Akcin -
Mel Beckman -
Michael Douglas -
Michael Thomas -
Miles Fidelman -
Nathan Stratton -
Nick Hilliard -
Owen DeLong -
Peter Kristolaitis -
Randy Bush -
Robert Raszuk -
Sabri Berisha -
Sander Steffann -
Shawn L -
Valdis Klētnieks -
Wayne Bouchard -
William Herrin -
Łukasz Bromirski