[SATLUG] Rackspace

Joe null.div.zero at gmail.com
Thu Nov 12 13:02:26 CST 2015


Well, I do appreciate all the information you've provided; now I know what
the hiring manager is thinking when he slips my resume into the trash ;).
But, I'm concerned some of this advice is overly black and white.  For
example:
 If I should not put that I "know subnetting, routing, and I have my
Network+" on my resume because I don't have a CCNA and have done most of my
work on SonicWalls rather than cisco, I would have nothing to put on my
resume; of course, I wouldn't be applying for a network Admin position
anyway.  Furthermore, while I can't say I'm proficient on Cisco CLI, I do
have some experience with it. I completed the icnd1 section of the cisco
simulator; although that was 2 years ago, and I would certainly not feel
comfortable dropped in the hot seat before a production terminal.
My point is, many people are not 10+ year veterans; and, are at many
different levels of proficiency.  And, while I'm not Jedi Knight of
Networking, Linux, or even fluent in any particular scripting/programming
language, I refuse to believe that means I have nothing to offer in these
areas.  Maybe you mean to say that Rackspace wouldn't be a good place for
me because their standard of proficiency is too high.  That's fine; but
rather than tell me what I can't do, or how unqualified I am for some
positions, what I was really hoping for from sending this email, was some
Ideas of what i can do.  Some ideas on career path options I can pursue.

Because, you're exactly right that I need to decide what I want; but, I
don't know what I want, because my interactions with like minded
individuals has been severely limited.  I love the idea of getting started
in Open Source. And, I'm looking for a project that interests me.  But, I
need to make a change sooner rather than later. And, right now, I don't
know if I want to be a Linux admin, a DBA, or hotdog cart vendor.

On Wed, Nov 11, 2015 at 1:38 AM, <typedeaf at yahoo.com> wrote:

> Interesting reply. It feels like you were replying to me in defense of
> some things I said. I was actually replying to the person who started the
> thread. So, I guess I will reply to you... and the original poster.
> Like all things, interviewing should be a constantly refined process. I
> used to be known as the guy that asked the hardest interview questions. I
> did not actually find that flattering, its just that my line of questions
> generally went lower level than what other people asked. So, in response to
> that feedback, I tried to refine my interview process each time, with two
> main goals in mind: 1. Determine if this person has the skills to do the
> job that they are interviewing for. 2. Try to make the interview process as
> painless as possible. Don't make them run away thinking you are a bunch of
> obnoxious a-holes (which is of course the reality.)
> When I went to interview for many of the big companies like Google,
> Facebook, and Amazon, I often got stuck in a room with a person who's goal
> was clearly to try to prove that I didn't know as much as they knew.
> Eventually a question is asked like, "How do you think they get the peanut
> centered in a M&M?", and my canned response became, "Is centering peanuts
> in M&Ms going to be part of my job requirement?" At some point youu just
> have to put an end to the absurdity. But be to prepared, and to expect it
> was my point.
> I worked with a guy that published a book on IT security. That guy didn't
> even know what an RBAC was, couldn't describe the purpose of a single
> non-general purpose register, or couldn't describe a single common web
> based attack vector. I worked with a guy that wrote the book on how to tune
> Oracle RAC for Linux, and that guy didn't know the difference between user
> and kernel address space mappings (talking 32-bit x86 era) or even what a
> I/O scheduler was. In my opinion, being the author or editor of a book
> qualifies you to be an author or editor of a book, and nothing more.
> >And virtually no host administrators I’ve known understand the first
> thing about networking, or network services like DNS, NTP, DHCP, or
> RADIUS. Are you saying that you have never met a single Linux admin that
> knows network services? That is crazy. I can not relate.
> You say you were asked absurd questions about DNS. This is the first
> question I asked about DNS every time, and still ask today. "Name 5 record
> types and describe what they are used for." 99% of the people who put DNS
> on their resume could not answer that question. If you have EVER added a
> new server to your DNS records, chances are extremely high that you added
> an A record, PTR record, maybe a CNAME record, and updated the serial in
> the SOA record. That leaves one more record to get the answer correct, and
> every admin worth his salt has performed a nslookup/dig to find the MX
> record when working with mailers. I don't think that is an absurd question,
> but hundreds of people would disagree with me.
>
> I used to say, "On a scale of 1-10, how well do you know Perl? 1 being,
> what is a pearl and 10 being I am Larry F'ing Wall" Invariably people would
> answer 7. Never 5. Never 6. Never 10. 7. So I would ask, "What the the
> three built in data type in perl?" If they were quiet, I would say, "Okay,
> I mean data types like scalars and arrays. Can you name one more?" 99% of
> the time, they couldn't say "hash", and when questioned further, they would
> say they have never used hashes. How could you be a 7:10 in Perl and never
> have had used a hash? Point is, know what you don't know, and do not BS
> your skill level.
> >Well, at least until I got into this DevOps thing, because so many places
> had decided overnight they could cut their staff in half by replacing all
> their “admins” with “DevOps” guys and make the people involved do twice as
> much work.You realize that statement is equivalent to saying, 'they cut
> their staff in half by replacing their "developers" with "Agile" guys',
> right? DevOps is a methodology for SA, not a job title. Most jobs hiring,
> "DevOps Engineers" are actually looking for people with experience in tools
> that aid in continuous integration and automation, like
> Chef/Puppet/Ansible. Some companies looking for "DevOps Engineers" are
> actually looking for SA that specialize in writing or heavily modifying
> existing automation tools written in HLL like Python, Ruby, Perl, Go, or
> even Bash. Unfortunately, that has mislead a lot of people into thinking
> that "DevOps" means a developer that also does operations.
> Chad WilsonSenior Peon II
>  Show original message
>
>
>
>
>      On Tuesday, November 10, 2015 10:03 PM, Brad Knowles <
> brad at shub-internet.org> wrote:
>
>
>  On Nov 10, 2015, at 2:06 PM, typedeaf at yahoo.com wrote:
>
> > In the end, I left Rackspace because there wasn't a path for where I
> wanted to go, and the pay was not very competitive given my skill set.
> > As for your current job skills, let me give you some harsh reality. When
> you say, "I know subnetting, routing, and I have my Network+", that doesn't
> really say much. What you are describing is a Network Admins primary skill
> set, but I am going to guess that you have never logged into a Cisco
> device. If you want to be a network admin, learn Cisco. I must have
> conducted 100+ interviews at Racksapce. In fact, I wrote/compiled the
> interview questionnaires. Interviews at big IT companies are BRUTALLY
> harsh. Be prepared to be thoroughly questioning on anything your resume is
> stating you know. So, if you think you know networking, be prepared to get
> drilled on the topic. Do you understand VLANs? How does VLAN tagging work?
> Where is the tag? What layer is VLAN tagging? What is the default VLAN and
> how is it used? How can you apply ACLs to VLANs? How can you replicate
> VLANs across multiple switches? What about link aggregations and the
> various protocols for it? What about STP? When do you need it and what does
> it do? These are all questions that a CCNA (basically L1 Cisco admin)
> should be able to answer. So make sure you clarify your knowledge of
> networks and routing before the interview starts. Make sure you know what
> you don't know, and don't be afraid to admit it. You will sound far less
> ignorant by admitting it, than trying to make up an answer and faking it.
>
> One of the things that killed me about the times I did actually have a
> phone interview with them, the person at the other end obviously didn’t
> know anything about the questions they were asking, and they were using a
> set from a public page.  They even gave me the URL to the page, so that I
> could read along.
>
> And every single question on that page had major problems.  I don’t
> remember the details, but I do remember challenging the fundamental basis
> of the question that was incorrect, and then having that thrown back at me
> as “WRONG!” because it wasn’t the precise answer that was typed into the
> form that they were reading from.
>
> If you’re going to ask me DNS questions because you see that I have DNS on
> my resume, that’s fine and dandy — just make sure that you ask good
> questions, or at least questions that are correctly formed, even if they
> are very simple.  Otherwise, as one of the Technical Reviewers of the book
> “DNS and BIND” by Albitz and Liu, I’m going to tear your questions apart.
> And if you’re not ready for that, then you’ve got a problem.
>
> Same with Sendmail — if you’re going to ask me e-mail/SMTP related
> questions, well you should be prepared for the fact that I was a technical
> reviewer for the book by Bryan Costales, and I’ve done a number of invited
> talks on the subject at various conferences like LISA.  There’s nothing
> quite like telling an entire room of people at LISA about how to scale
> sendmail system performance, while you’ve got Eric Allman sitting in the
> front row.
>
>
> On the subject of doing an interview, on either side of the desk, I would
> say that the most important thing is to know when to say that you don’t
> know the answer but that you can look it up.  If someone quizzes me on
> arcane command-line parameters for a particular program, I may well tell
> them that I don’t know the specifics of that particular version of that
> particular program, because I’ve dealt with dozens of different versions of
> that program over the years — but I can look it up on the man page.  And if
> they can’t accept that answer, then odds are that’s not a place I want to
> work.
>
> On the flip side, I know a bit about networking, but I’m certainly no
> CCNA, and if they were to start throwing those kind of questions at me then
> I would tell them that.  Again, if they can’t accept that answer, then
> that’s not a good place for me.
>
>
> A few of years back, I interviewed for a position as a senior engineer at
> Bazaarvoice.  I was going to be working in a DevOps position for Ernest
> Mueller, who is a guy I consider a friend of mine from the Austin Cloud
> User Group.  Frankly, I thought that interview went pretty well.
>
> But there was this one guy who kept asking me various questions about how
> to set up web servers, and I kept telling him that I’m a general
> performance tuning guy and I don’t know a great deal of specifics of doing
> performance tuning for web, but that I could learn.
>
> I never did get that job.  And Ernest never told me the reasons why.
> However, it wasn’t too long before Ernest left that company and went
> somewhere else.  So, maybe my honesty about “I’m not a web guy” cost me
> that job.  Or maybe Ernest saved me from disaster.
>
>
> Don’t be afraid to say that you don’t know.  Be open about how you would
> go about finding out how to answer that question.
>
> When I’m on the other end of the table, I don’t want anyone to try to
> “baffle me with bullshit”.  Skills and knowledge can be taught, but talent
> for problem solving and learning can’t.
>
> In those circumstances, I want to push you to the limits of your
> knowledge, so that you can give me an indication as to how you would go
> about finding the answer to a problem.
>
> > That being said, every 'admin' , wether DBA or SA or MW admin, should
> know at least basic LAN networking. I can't tell you how many times I have
> seen people hit a brick wall and throw their hands in the air at some
> issue, just to find out that they do not have a reasonable default gateway
> set.
>
> Or they don’t have proper nameservers set up.  Or they don’t understand
> about path MTU discovery.  Or they don’t understand how the TCP three-way
> handshake works.
>
> And so many more.
>
> > Networking at Rackapce was and probably still is its own island. They
> have traditional networking admin that work on LAN issues, and they have
> 'Network Security' roles that focus on 'security' devices --primarily
> firewalls, but also load balancers and other devices that are not straight
> up switches and routers. The Cisco people did not know Linux, and the Linux
> people did not know Cisco.
>
> That’s been my experience at virtually every place I’ve ever worked.  Most
> networking guys also don’t really understand how certain network services
> work, if they don’t run on routers or switches.  So, they don’t really
> understand DNS.  Or NTP.  They might (or might not) understand about DHCP
> or RADIUS.
>
> And virtually no host administrators I’ve known understand the first thing
> about networking, or network services like DNS, NTP, DHCP, or RADIUS.
>
> Which leaves a nice little hole in the middle that I made a career out of
> specializing in.
>
> Well, at least until I got into this DevOps thing, because so many places
> had decided overnight they could cut their staff in half by replacing all
> their “admins” with “DevOps” guys and make the people involved do twice as
> much work.
>
> --
> Brad Knowles <brad at shub-internet.org>
> LinkedIn Profile: <http://tinyurl.com/y8kpxu>
>
> --
> _______________________________________________
> SATLUG mailing list
> SATLUG at satlug.org
> http://alamo.satlug.org/mailman/listinfo/satlug to manage/unsubscribe
> Powered by Rackspace (www.rackspace.com)
>
>
> --
> _______________________________________________
> SATLUG mailing list
> SATLUG at satlug.org
> http://alamo.satlug.org/mailman/listinfo/satlug to manage/unsubscribe
> Powered by Rackspace (www.rackspace.com)
>


More information about the SATLUG mailing list