Re: Has virtualization become obsolete in 5G?

[Ahmed elBorno]

Maybe I am off topic a little bit here and i'd like to be educated if i am
wrong but I think those 5G applications will move from VMs into
containers/microservices when their vendors see a business case to
rearchitect them, maybe its already happening as we speak.

On the other side of that coin is that product managers of these 5G apps
seeing the margins on their apps diminish when they slice them to a form
that allows other "orchestrators" to deploy them.

Another side is that the software engineers working on these Apps have a
lot more prioritized items/things to develop (real core functions) so they
will delay this transformation.

However, some CSPs are doing well putting a wrapper/UX around Mobility
(e.g: Twilio)

Cheers

On Sat, Aug 1, 2020 at 6:36 PM John Levine  wrote:

> In article <20200801143522.e25a8...@m0117164.ppops.net> you write:
> >--- ed...@ieee.org wrote:
> >From: Etienne-Victor Depasquale 
> >
> >See, for example, Azhar Sayeed's (Red Hat) contribution here
> >@15:33.
> >
> >
> >
> >Don't send links to this list that require one to register
> >to read the article and then say, "By registering for our
> >site, your email will be added to our promotions list" and
> >"Occasionally our trusted partners may want to send you
> >information about exciting new products and services"
> >
> >No one's going to click on that!
>
> Sure we are.  That's what mailinator is for.
>
> R's,
> John
>

Re: questions asked during network engineer interview

[Ahmed elBorno]

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

I had less than two years experience.

The interviewer asked me:

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

I'll never forget this :)

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

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