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