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.
My general feelings on the subject of tech interviews are summarized in the “interview anti-loop” section of this article by Steve Yegge. Although it is targeted to people seeking software engineering jobs at FANG (and FANG-like) companies, IMO the general tone is applicable to other tech careers, even network engineering. I have seen numerous articles (and subsequent discussions) on this subject on forums such as Quora, Medium, and Hacker News.
—gregbo
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:
Mike
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:
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.
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?”.
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
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:
I’ll never forget this 
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
"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
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
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
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
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
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
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
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
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
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