Re: questions asked during network engineer interview

[Ahmed elBorno <amaged () gmail com>]

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