typedeaf at yahoo.com
typedeaf at yahoo.com
Wed Nov 11 01:38:04 CST 2015
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)
More information about the SATLUG