Hi folks, I gave my HR folks a screening question to ask candidates for an IP expert position. I've gotten some "unexpected" answers, so I want to do a sanity check and make sure I'm not asking something unreasonable. And by "unexpected" I don't mean naively incorrect answers, I mean oh-my-God-how-did-you-get-that-cisco-certification answers. The question was: You implement a firewall on which you block all ICMP packets. What part of the TCP protocol (not IP in general, TCP specifically) malfunctions as a result? My questions for you are: 1. As an expert who follows NANOG, do you know the answer? Or is this question too hard? 2. Is the question too vague? Is there a clearer way to word it? 3. Is there a better screening question I could pass to HR to ask and check the candidate's response against the supplied answer? Thanks, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
My answer to that questionwould be "No..why would I ever blanket block ICMP? If I'm that stupid, I shouldn't be deploying firewalls at all." I also assume I wouldn't get the job after answering that... Thomas York -----Original Message----- From: William Herrin [mailto:bill@herrin.us] Sent: Thursday, July 05, 2012 1:02 PM To: nanog@nanog.org Subject: job screening question Hi folks, I gave my HR folks a screening question to ask candidates for an IP expert position. I've gotten some "unexpected" answers, so I want to do a sanity check and make sure I'm not asking something unreasonable. And by "unexpected" I don't mean naively incorrect answers, I mean oh-my-God-how-did-you-get-that-cisco-certification answers. The question was: You implement a firewall on which you block all ICMP packets. What part of the TCP protocol (not IP in general, TCP specifically) malfunctions as a result? My questions for you are: 1. As an expert who follows NANOG, do you know the answer? Or is this question too hard? 2. Is the question too vague? Is there a clearer way to word it? 3. Is there a better screening question I could pass to HR to ask and check the candidate's response against the supplied answer? Thanks, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Seems fairly straightforward to me. It'll break path MTU discovery. I would hope someone applying for an "IP expert" position would know that. Could HR be mangling the question or something? Oliver ------------------------------------- Oliver Garraux Check out my blog: www.GetSimpliciti.com/blog Follow me on Twitter: twitter.com/olivergarraux On Thu, Jul 5, 2012 at 1:02 PM, William Herrin <bill@herrin.us> wrote:
Hi folks,
I gave my HR folks a screening question to ask candidates for an IP expert position. I've gotten some "unexpected" answers, so I want to do a sanity check and make sure I'm not asking something unreasonable. And by "unexpected" I don't mean naively incorrect answers, I mean oh-my-God-how-did-you-get-that-cisco-certification answers.
The question was:
You implement a firewall on which you block all ICMP packets. What part of the TCP protocol (not IP in general, TCP specifically) malfunctions as a result?
My questions for you are:
1. As an expert who follows NANOG, do you know the answer? Or is this question too hard?
2. Is the question too vague? Is there a clearer way to word it?
3. Is there a better screening question I could pass to HR to ask and check the candidate's response against the supplied answer?
Thanks, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 7/5/2012 1:11 PM, Oliver Garraux wrote:
Seems fairly straightforward to me. It'll break path MTU discovery.
I would hope someone applying for an "IP expert" position would know that.
Could HR be mangling the question or something?
Oliver
-------------------------------------
Oliver Garraux Check out my blog: www.GetSimpliciti.com/blog Follow me on Twitter: twitter.com/olivergarraux
On Thu, Jul 5, 2012 at 1:02 PM, William Herrin <bill@herrin.us> wrote:
Hi folks,
I gave my HR folks a screening question to ask candidates for an IP expert position. I've gotten some "unexpected" answers, so I want to do a sanity check and make sure I'm not asking something unreasonable. And by "unexpected" I don't mean naively incorrect answers, I mean oh-my-God-how-did-you-get-that-cisco-certification answers.
The question was:
You implement a firewall on which you block all ICMP packets. What part of the TCP protocol (not IP in general, TCP specifically) malfunctions as a result?
My questions for you are:
1. As an expert who follows NANOG, do you know the answer? Or is this question too hard?
2. Is the question too vague? Is there a clearer way to word it?
3. Is there a better screening question I could pass to HR to ask and check the candidate's response against the supplied answer?
Thanks, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
You would be surprised by some of the people I get off the street applying for senior network engineering positions who couldn't connect up a SOHO router and a dumb switch and make them work, let alone understand how PMTU discovery works. -- --- James M Keller
On Thu, Jul 5, 2012 at 1:11 PM, Oliver Garraux <oliver@g.garraux.net> wrote:
Seems fairly straightforward to me. It'll break path MTU discovery.
Since Bill said "(not IP in general, TCP specifically)", I don't think PMTUD breaking is what he's looking for. I'd venture more along the lines of lack of Destination Unreachables making things hang. -- Darius Jahandarie
On Jul 5, 2012, at 10:20 AM, Darius Jahandarie <djahandarie@gmail.com> wrote:
On Thu, Jul 5, 2012 at 1:11 PM, Oliver Garraux <oliver@g.garraux.net> wrote:
Seems fairly straightforward to me. It'll break path MTU discovery.
Since Bill said "(not IP in general, TCP specifically)", I don't think PMTUD breaking is what he's looking for.
I'd venture more along the lines of lack of Destination Unreachables making things hang.
All of DU failing, path MTU discovery, and congestion control / source quench might be the right / expected answer, which makes this a not great question. DU doesn't break TCP per se but would hang sessions until timeout; path MTU isn't a TCP function per se, though it uses TCP as the probe. Source quench is only a small fraction of the TCP congestion control solution space now. My systems consulting company uses a HR prescreen of 20 questions. It took a team of senior consultants and HR some years to tune the questions in. They need to be clear, have unambiguously correct answers, the answer correctness needs to be obvious to the HR / recruiter who isn't technical. I think this one fails to have an unambiguously correct answer and an answer the non-tech recruiter / HR person will understand. So, probably time for a better question... George William Herbert Sent from my iPhone
On Thu, Jul 5, 2012 at 1:20 PM, Darius Jahandarie <djahandarie@gmail.com> wrote:
On Thu, Jul 5, 2012 at 1:11 PM, Oliver Garraux <oliver@g.garraux.net> wrote:
Seems fairly straightforward to me. It'll break path MTU discovery.
Since Bill said "(not IP in general, TCP specifically)", I don't think PMTUD breaking is what he's looking for.
No, path MTU discovery is the answer I'm fishing for. The stack notifies TCP of the fragmentation needed message and TCP handles it within the TCP stack. Managing path MTU discovery is specific to each layer-4 protocol even if the trigger message (destination unreachable, fragmentation needed but DF set) is the same. If a candidate gives me a more clever answer, I'd take that too. :-) "This would block all IP traffic." is not a correct answer. It's not even a naively incorrect answer. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
This is exactly the issue comcast6.net is currently experiencing :). They seem to be blocking ICMP completely and that is causing my HE IPv6 tunnel to be unable to access their site from a browser. On Jul 5, 2012, at 1:41 PM, William Herrin wrote:
On Thu, Jul 5, 2012 at 1:20 PM, Darius Jahandarie <djahandarie@gmail.com> wrote:
On Thu, Jul 5, 2012 at 1:11 PM, Oliver Garraux <oliver@g.garraux.net> wrote:
Seems fairly straightforward to me. It'll break path MTU discovery.
Since Bill said "(not IP in general, TCP specifically)", I don't think PMTUD breaking is what he's looking for.
No, path MTU discovery is the answer I'm fishing for. The stack notifies TCP of the fragmentation needed message and TCP handles it within the TCP stack. Managing path MTU discovery is specific to each layer-4 protocol even if the trigger message (destination unreachable, fragmentation needed but DF set) is the same.
If a candidate gives me a more clever answer, I'd take that too. :-)
"This would block all IP traffic." is not a correct answer. It's not even a naively incorrect answer.
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Thu, Jul 05, 2012 at 01:45:54PM -0400, Derek Ivey wrote:
This is exactly the issue comcast6.net is currently experiencing :). They seem to be blocking ICMP completely and that is causing my HE IPv6 tunnel to be unable to access their site from a browser.
I've recently came across a dualstacked website which fails behind a SixXS tunnel (MTU=1280) but works fine with a native connection (MTU=1500). Having contacted their technical staff, we have diagnosed the issue down to the dualstacked load balancer (pretty well-known brand) SOMETIMES not reacting on ICMPv6 PTB errors. It's not always as easy as "blocks all ICMPv6". For all the cases I've hunted down to root cause in the last decade, it was never a firewall blocking ICMPv6, but most times misbehaving load balancers, either due to bugs or plain not having implemented PMTUD on IPv6. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On Thu, Jul 5, 2012 at 1:42 PM, William Herrin wrote:
No, path MTU discovery is the answer I'm fishing for.
The "TCP specifically" part of the question confused the heck out of me. PMTUD is an IP function in every way as far as I'm concerned. (If you're saying that the way it's actually coded makes it more like a TCP function, I'd still change the wording unless you're hiring people to write network drivers.) -Terry
He might be thinking of the MMS adjustment as a result of PMTUD, which most people forget about BTW, but I agree: PMTUD isn't about TCP, so tossing TCP in there just makes it a very odd question. On Thu, Jul 5, 2012 at 4:04 PM, Terry Baranski <terry.baranski.list@gmail.com> wrote:
On Thu, Jul 5, 2012 at 1:42 PM, William Herrin wrote:
No, path MTU discovery is the answer I'm fishing for.
The "TCP specifically" part of the question confused the heck out of me. PMTUD is an IP function in every way as far as I'm concerned. (If you're saying that the way it's actually coded makes it more like a TCP function, I'd still change the wording unless you're hiring people to write network drivers.)
-Terry
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
That's a horrible question for a non-technical HR person to pose to a candidate - It's impossible for the candidate to ask clarifying questions to make sure they understand what you are looking for, plus you may have a strong candidate who gets it wrong (for whatever reason), but if they were talking to a technical person you would realize they were 99% of the way there. What if they said "it would cause the generation of port-unreachable ICMP packets to cease, and applications may hang until they timeout"? Not the answer you're looking for, but not wrong either. I leave HR to their standard screening stuff, and do the technical part myself. Less chance to skip over a good candidate, even if it takes a bit longer in the whole process. On 7/5/12 1:02 PM, William Herrin wrote:
Hi folks,
I gave my HR folks a screening question to ask candidates for an IP expert position. I've gotten some "unexpected" answers, so I want to do a sanity check and make sure I'm not asking something unreasonable. And by "unexpected" I don't mean naively incorrect answers, I mean oh-my-God-how-did-you-get-that-cisco-certification answers.
The question was:
You implement a firewall on which you block all ICMP packets. What part of the TCP protocol (not IP in general, TCP specifically) malfunctions as a result?
My questions for you are:
1. As an expert who follows NANOG, do you know the answer? Or is this question too hard?
2. Is the question too vague? Is there a clearer way to word it?
3. Is there a better screening question I could pass to HR to ask and check the candidate's response against the supplied answer?
Thanks, Bill Herrin
On Thu, Jul 5, 2012 at 1:16 PM, David Coulson <david@davidcoulson.net> wrote:
That's a horrible question for a non-technical HR person to pose to a candidate - It's impossible for the candidate to ask clarifying questions to make sure they understand what you are looking for, plus you may have a strong candidate who gets it wrong (for whatever reason), but if they were talking to a technical person you would realize they were 99% of the way there. What if they said "it would cause the generation of port-unreachable ICMP packets to cease, and applications may hang until they timeout"? Not the answer you're looking for, but not wrong either.
Hi David, To clarify: I asked HR to forward me the candidate's answer along with their resume. Just in case of answers like that one. Which would be more than enough to proceed to a phone screen directly with me. Regards, Bill -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Bill- So, I'm curious, and others probably are too. What's the most popular 'wrong' answer? :) David On 7/5/12 1:35 PM, William Herrin wrote:
On Thu, Jul 5, 2012 at 1:16 PM, David Coulson <david@davidcoulson.net> wrote:
That's a horrible question for a non-technical HR person to pose to a candidate - It's impossible for the candidate to ask clarifying questions to make sure they understand what you are looking for, plus you may have a strong candidate who gets it wrong (for whatever reason), but if they were talking to a technical person you would realize they were 99% of the way there. What if they said "it would cause the generation of port-unreachable ICMP packets to cease, and applications may hang until they timeout"? Not the answer you're looking for, but not wrong either. Hi David,
To clarify: I asked HR to forward me the candidate's answer along with their resume. Just in case of answers like that one. Which would be more than enough to proceed to a phone screen directly with me.
Regards, Bill
On Thu, Jul 5, 2012 at 10:16 AM, David Coulson <david@davidcoulson.net>wrote:
What if they said "it would cause the generation of port-unreachable ICMP packets to cease, and applications may hang until they timeout"? Not the answer you're looking for, but not wrong either.
Umm, yeah, it is wrong. The question was TCP. TCP doesn't send ICMP Port-Unreach, it sends RST packets. Scott
In a message written on Thu, Jul 05, 2012 at 01:02:08PM -0400, William Herrin wrote:
You implement a firewall on which you block all ICMP packets. What part of the TCP protocol (not IP in general, TCP specifically) malfunctions as a result?
My questions for you are:
1. As an expert who follows NANOG, do you know the answer? Or is this question too hard?
I suspect you're looking for Path MTU Discovery as an answer.
2. Is the question too vague? Is there a clearer way to word it?
I believe if you understand ICMP, it could be considered to be vague. For instance, blocking all ICMP means that if the network breaks during communication and a Host/Net unreachable is generated the connection will have to go through a timeout rather than an immeidate tear down. Similarly, blocking ICMP source quench might break throttling in the 3 TCP implementations in the world that do that. :)
3. Is there a better screening question I could pass to HR to ask and check the candidate's response against the supplied answer?
"A firewall is configured to block all ICMP packets and a system administrator reports problems with TCP connections not transferring data. What is the most likely cause?" ICMP Packet-Too-Big being dropped and breaking PMTU discovery is the correct answer. When I study for my CCIE Recert every 2 years I find myself relearning "The Cisco Answer", rather than the right answer. It's not that the Cisco answers are often wrong per-se, but they teach the most likely causes of things and want them back as the right answer. Cribbing from their test materials and study guides puts the questions in familar terms that your candidates are likely to have seen, making them less likely to be thrown off by the question. Unless you want to throw them off. Depends on the level of folks you want to hire. I would answer your question with "I would never implement a firewall that breaks all TCP." :) -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
I think if your goal is to see if they know that your shouldn't blindly filter ICMP for IPv6, and you're specifically looking for knowledge of PMTUD, then a better question would be "Please list the problems that could occur if all ICMPv6 traffic is blocked between two host systems." Which should get you a minimum of neighbor discovery, and up into PMTUD for those who have some knowledge on the subject. If you just say ICMP your answers will be all over the place since blocking of ICMP outright for endpoints is rampant today in the IPv4 world. They might even know the answer but not think of it because of the lack of context. I generally try to stay away from any question that has a definitive answer, as that will only tell you if they happened to read and retain that piece of information somewhere along the way. In my experience, people who have an "OK" understanding of Layer-3, might not always have a good understanding of what happens below that. A better approach might be to have an open ended question that asks them to describe what events will take place for a pair of host systems to communicate in as much detail as they can. If you're asking the question you can leave it intentionally vague and use the questions they ask to evaluate their ability to work through problems; if it needs to be asked by HR then you can narrow it down to include more detail. A good applicant should be able to explain the ARP process at a minimum. If they can't they have no business being in networking in a question like this. I know it sounds trivial, but you'd be surprised how many "experts" I've met who go blank at a question like this. Even more telling than a correct answer is an incorrect answer. I'm always on the look-out for IT people who like to make stuff up; I have no tolerance for that. On Thu, Jul 5, 2012 at 1:02 PM, William Herrin <bill@herrin.us> wrote:
Hi folks,
I gave my HR folks a screening question to ask candidates for an IP expert position. I've gotten some "unexpected" answers, so I want to do a sanity check and make sure I'm not asking something unreasonable. And by "unexpected" I don't mean naively incorrect answers, I mean oh-my-God-how-did-you-get-that-cisco-certification answers.
The question was:
You implement a firewall on which you block all ICMP packets. What part of the TCP protocol (not IP in general, TCP specifically) malfunctions as a result?
My questions for you are:
1. As an expert who follows NANOG, do you know the answer? Or is this question too hard?
2. Is the question too vague? Is there a clearer way to word it?
3. Is there a better screening question I could pass to HR to ask and check the candidate's response against the supplied answer?
Thanks, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
This type o question where the candidate can elaborate the answer should be asked by a techinal interviewer. For screening questions (for 1st level filtering), IMO, the questions has to be straight to the point, for example: 1) What is the LSA number for an external route in OSPF? This can have two answer: 5 or 7. So, I will accept if the candidate answer 5, 7 or 5 and 7. Later on (the next level of the interview), a techinical interviewer will chech if the candidate understand the differences of LSA 5 and 7. The point is that the candidate cannot deviate from the question, I.e., this question will not generate another question from the candidate to the interviewer asking for more details about the scenario in case. For example, you may ask: which IGP is more reliable under an IP DoS attack? The answer for this question can be very long or may require some sort of interaction between the candidate and the interviewer, which means it has to be asked by techinical people and not by non-techinical interviewers. Thanks On 7/6/12, William Herrin <bill@herrin.us> wrote:
Hi folks,
I gave my HR folks a screening question to ask candidates for an IP expert position. I've gotten some "unexpected" answers, so I want to do a sanity check and make sure I'm not asking something unreasonable. And by "unexpected" I don't mean naively incorrect answers, I mean oh-my-God-how-did-you-get-that-cisco-certification answers.
The question was:
You implement a firewall on which you block all ICMP packets. What part of the TCP protocol (not IP in general, TCP specifically) malfunctions as a result?
My questions for you are:
1. As an expert who follows NANOG, do you know the answer? Or is this question too hard?
2. Is the question too vague? Is there a clearer way to word it?
3. Is there a better screening question I could pass to HR to ask and check the candidate's response against the supplied answer?
Thanks, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
-- Sent from my mobile device ./diogo -montagner JNCIE-M 0x41A
Diogo Montagner <diogo.montagner@gmail.com> writes:
For screening questions (for 1st level filtering), IMO, the questions has to be straight to the point, for example:
1) What is the LSA number for an external route in OSPF?
This can have two answer: 5 or 7. So, I will accept if the candidate answer 5, 7 or 5 and 7. Later on (the next level of the interview), a techinical interviewer will chech if the candidate understand the differences of LSA 5 and 7.
Frankly, this feels a bit like asking what the 9th byte in an IP header is used for (it's TTL, but who's, uh, counting?) -- "That's why God gave us packet analyzers" should be counted as an acceptable answer. If not, you'll find yourself skipping over plenty of extremely well qualified candidates in favor of those who have crammed recently for some sort of exam in hopes of compensating for their short CV. -r
On Thu, Jul 05, 2012 at 11:04:05PM -0400, Robert E. Seastrom wrote:
Diogo Montagner <diogo.montagner@gmail.com> writes:
For screening questions (for 1st level filtering), IMO, the questions has to be straight to the point, for example:
1) What is the LSA number for an external route in OSPF?
This can have two answer: 5 or 7. So, I will accept if the candidate answer 5, 7 or 5 and 7. Later on (the next level of the interview), a techinical interviewer will chech if the candidate understand the differences of LSA 5 and 7.
Frankly, this feels a bit like asking what the 9th byte in an IP header is used for (it's TTL, but who's, uh, counting?) -- "That's why God gave us packet analyzers" should be counted as an acceptable answer. If not, you'll find yourself skipping over plenty of extremely well qualified candidates in favor of those who have crammed recently for some sort of exam in hopes of compensating for their short CV.
Ugh, I know someone (thankfully no longer a current colleague) who ardently *defends* his use of questions like "what does the -M option to ps do?" on the basis that "any senior person who knows what they're doing should know all the options to ps!". No, you useless tit, anyone who knows what they're doing should know how to read a bloody manpage. Trivia tests get you hiring people who know trivia. Knowing trivia has it's productivity benefits, but if you can't apply it, it's useless. - Matt -- Politics and religion are just like software and hardware. They all suck, the documentation is provably incorrect, and all the vendors tell lies. -- Andrew Dalgleish, in the Monastery
Ugh, I know someone (thankfully no longer a current colleague) who ardently *defends* his use of questions like "what does the -M option to ps do?" on the basis that "any senior person who knows what they're doing should know all the options to ps!". No, you useless tit, anyone who knows what they're doing should know how to read a bloody manpage.
Beyond that, if by "Senior" the role is the one the other tech people turn to when they're out of knowledge/skills/ability, there's just too much breadth to remember every detail about every tool. Quite the opposite from remembering every option to a tool, it's impossible to even keep track of every tool. The job as "senior" people is to figure out the stuff that we don't always know within that company. The main benefit of questions for HR to ask is the bozon filter: make sure it's actually someone who does network, or systems, or database, or whatever work. If one question (or even 10) could reveal the level of responsibility someone were capable of, we wouldn't need the interview process.
I agree. Let the person talk do a few probing questions based off what they say. If you yourself have any value you should be able to tell if they have a chance. Also I would prefer someone who says I don't know for sure but maybe something along these lines, and then wants to know the right answer. Passion is also important, if you are willing to hire someone who is in it for just a paycheck, save yourself the headache and get a contractor. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Matthew Palmer <mpalmer@hezmatt.org> wrote: On Thu, Jul 05, 2012 at 11:04:05PM -0400, Robert E. Seastrom wrote:
Diogo Montagner <diogo.montagner@gmail.com> writes:
For screening questions (for 1st level filtering), IMO, the questions has to be straight to the point, for example:
1) What is the LSA number for an external route in OSPF?
This can have two answer: 5 or 7. So, I will accept if the candidate answer 5, 7 or 5 and 7. Later on (the next level of the interview), a techinical interviewer will chech if the candidate understand the differences of LSA 5 and 7.
Frankly, this feels a bit like asking what the 9th byte in an IP header is used for (it's TTL, but who's, uh, counting?) -- "That's why God gave us packet analyzers" should be counted as an acceptable answer. If not, you'll find yourself skipping over plenty of extremely well qualified candidates in favor of those who have crammed recently for some sort of exam in hopes of compensating for their short CV.
Ugh, I know someone (thankfully no longer a current colleague) who ardently *defends* his use of questions like "what does the -M option to ps do?" on the basis that "any senior person who knows what they're doing should know all the options to ps!". No, you useless tit, anyone who knows what they're doing should know how to read a bloody manpage. Trivia tests get you hiring people who know trivia. Knowing trivia has it's productivity benefits, but if you can't apply it, it's useless. - Matt -- Politics and religion are just like software and hardware. They all suck, the documentation is provably incorrect, and all the vendors tell lies. -- Andrew Dalgleish, in the Monastery
A former manager of mine once told me you can gauge a persons understanding by the questions they ask and I personally agree with this statement. Most of us will be able to make a reasonable assessment of the person by listening to the content of their questions. I'm not looking for an immediate resolution, but trying to understand the thought process of the individual. I feel realistic scenarios provide some insight on the individual's analytical skills. "A client cannot access the website "http://xyz.com". What do you do to troubleshoot this issue?" Depending on the candidate, I've seen a variety of answers: 1) "Can you ping the device?" 2) "Can you access the gateway?" 3) "What does the running config look like on the router" 4) "Is there a firewall in between" I believe these questions may be asked in the right context provided there is enough information to isolate the issue to the network however the statement is devoid of anything useful that would make the network suspect. I would like to hear some questions such as: "are other websites accessible? Or is the only website the client is experiencing issues with?" "was the website working previously? when did it start happening?" "what does the client see on their screen ? are they getting an error?" These questions reflect the persons ability to accurately understand the problem before deep diving into the technical details. From there, you can get more technical. "Client is receiving an HTTP 404 error." Great, rule out network since this is an application layer response... just my .02. On Fri, Jul 6, 2012 at 8:28 AM, <joseph.snyder@gmail.com> wrote:
I agree. Let the person talk do a few probing questions based off what they say. If you yourself have any value you should be able to tell if they have a chance.
Also I would prefer someone who says I don't know for sure but maybe something along these lines, and then wants to know the right answer. Passion is also important, if you are willing to hire someone who is in it for just a paycheck, save yourself the headache and get a contractor. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Matthew Palmer <mpalmer@hezmatt.org> wrote:
On Thu, Jul 05, 2012 at 11:04:05PM -0400, Robert E. Seastrom wrote:
Diogo Montagner <diogo.montagner@gmail.com> writes:
For screening questions (for 1st level filtering), IMO, the questions has to be straight to the point, for example:
1) What is the LSA number for an external route in OSPF?
This can have two answer: 5 or 7. So, I will accept if the candidate answer 5, 7 or 5 and 7. Later on (the next level of the interview), a techinical interviewer will chech if the candidate understand the differences of LSA 5 and 7.
Frankly, this feels a bit like asking what the 9th byte in an IP header is used for (it's TTL, but who's, uh, counting?) -- "That's why God gave us packet analyzers" should be counted as an acceptable answer. If not, you'll find yourself skipping over plenty of extremely well qualified candidates in favor of those who have crammed recently for some sort of exam in hopes of compensating for their short CV.
Ugh, I know someone (thankfully no longer a current colleague) who ardently *defends* his use of questions like "what does the -M option to ps do?" on the basis that "any senior person who knows what they're doing should know all the options to ps!". No, you useless tit, anyone who knows what they're doing should know how to read a bloody manpage.
Trivia tests get you hiring people who know trivia. Knowing trivia has it's productivity benefits, but if you can't apply it, it's useless.
- Matt
-- Politics and religion are just like software and hardware. They all suck, the documentation is provably incorrect, and all the vendors tell lies. -- Andrew Dalgleish, in the Monastery
-- -Matt Chung
My response would be "insufficient information provided for meaningful diagnosis". The following could be issues: ... the user does not have a computer ... the computer is not turned on ... the keyboard is not plugged in ... the user is a quadraplegic and cannot use the mouse or keyboard ... the user is blind and cannot find the computer ... the user has a computer but is not connected to a network ... the monitor is not turned on ... the brightness is turned down too far on the monitor ... the user is dead How does the user know that it cannot access the web site? --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
-----Original Message----- From: Matt Chung [mailto:itsmemattchung@gmail.com] Sent: Friday, 06 July, 2012 08:20 To: joseph.snyder@gmail.com Cc: nanog@nanog.org Subject: Re: job screening question
A former manager of mine once told me you can gauge a persons understanding by the questions they ask and I personally agree with this statement. Most of us will be able to make a reasonable assessment of the person by listening to the content of their questions. I'm not looking for an immediate resolution, but trying to understand the thought process of the individual. I feel realistic scenarios provide some insight on the individual's analytical skills.
"A client cannot access the website "http://xyz.com". What do you do to troubleshoot this issue?"
Depending on the candidate, I've seen a variety of answers: 1) "Can you ping the device?" 2) "Can you access the gateway?" 3) "What does the running config look like on the router" 4) "Is there a firewall in between"
I believe these questions may be asked in the right context provided there is enough information to isolate the issue to the network however the statement is devoid of anything useful that would make the network suspect. I would like to hear some questions such as:
"are other websites accessible? Or is the only website the client is experiencing issues with?" "was the website working previously? when did it start happening?" "what does the client see on their screen ? are they getting an error?"
These questions reflect the persons ability to accurately understand the problem before deep diving into the technical details. From there, you can get more technical. "Client is receiving an HTTP 404 error." Great, rule out network since this is an application layer response...
just my .02.
On Fri, Jul 6, 2012 at 8:28 AM, <joseph.snyder@gmail.com> wrote:
I agree. Let the person talk do a few probing questions based off what they say. If you yourself have any value you should be able to tell if they have a chance.
Also I would prefer someone who says I don't know for sure but maybe something along these lines, and then wants to know the right answer. Passion is also important, if you are willing to hire someone who is in it for just a paycheck, save yourself the headache and get a contractor. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Matthew Palmer <mpalmer@hezmatt.org> wrote:
On Thu, Jul 05, 2012 at 11:04:05PM -0400, Robert E. Seastrom wrote:
Diogo Montagner <diogo.montagner@gmail.com> writes:
For screening questions (for 1st level filtering), IMO, the questions has to be straight to the point, for example:
1) What is the LSA number for an external route in OSPF?
This can have two answer: 5 or 7. So, I will accept if the candidate answer 5, 7 or 5 and 7. Later on (the next level of the interview), a techinical interviewer will chech if the candidate understand the differences of LSA 5 and 7.
Frankly, this feels a bit like asking what the 9th byte in an IP header is used for (it's TTL, but who's, uh, counting?) -- "That's why God gave us packet analyzers" should be counted as an acceptable answer. If not, you'll find yourself skipping over plenty of extremely well qualified candidates in favor of those who have crammed recently for some sort of exam in hopes of compensating for their short CV.
Ugh, I know someone (thankfully no longer a current colleague) who ardently *defends* his use of questions like "what does the -M option to ps do?" on the basis that "any senior person who knows what they're doing should know all the options to ps!". No, you useless tit, anyone who knows what they're doing should know how to read a bloody manpage.
Trivia tests get you hiring people who know trivia. Knowing trivia has it's productivity benefits, but if you can't apply it, it's useless.
- Matt
-- Politics and religion are just like software and hardware. They all suck, the documentation is provably incorrect, and all the vendors tell lies. -- Andrew Dalgleish, in the Monastery
-- -Matt Chung
On Jul 6, 2012, at 11:41 AM, Keith Medcalf wrote:
My response would be "insufficient information provided for meaningful diagnosis".
The following could be issues: ... the user does not have a computer ... the computer is not turned on ... the keyboard is not plugged in ... the user is a quadraplegic and cannot use the mouse or keyboard ... the user is blind and cannot find the computer ... the user has a computer but is not connected to a network ... the monitor is not turned on ... the brightness is turned down too far on the monitor ... the user is dead
I would argue that the fact the user filed a ticket/contacted the helpdesk/whatever to raise the issue indicates that the user probably isn't dead. The rest are semi-legitimate somewhat amusing answers, but you missed many possibilities. When providing such a list of answers, always include an etc. at the end so as to indicate your understanding that the list is not complete. ;-)
How does the user know that it cannot access the web site?
When did users become things? Probably a candidate that made this mistake should be dismissed from consideration on that basis alone. Owen
-----Original Message----- From: Matt Chung [mailto:itsmemattchung@gmail.com] Sent: Friday, 06 July, 2012 08:20 To: joseph.snyder@gmail.com Cc: nanog@nanog.org Subject: Re: job screening question
A former manager of mine once told me you can gauge a persons understanding by the questions they ask and I personally agree with this statement. Most of us will be able to make a reasonable assessment of the person by listening to the content of their questions. I'm not looking for an immediate resolution, but trying to understand the thought process of the individual. I feel realistic scenarios provide some insight on the individual's analytical skills.
"A client cannot access the website "http://xyz.com". What do you do to troubleshoot this issue?"
Depending on the candidate, I've seen a variety of answers: 1) "Can you ping the device?" 2) "Can you access the gateway?" 3) "What does the running config look like on the router" 4) "Is there a firewall in between"
I believe these questions may be asked in the right context provided there is enough information to isolate the issue to the network however the statement is devoid of anything useful that would make the network suspect. I would like to hear some questions such as:
"are other websites accessible? Or is the only website the client is experiencing issues with?" "was the website working previously? when did it start happening?" "what does the client see on their screen ? are they getting an error?"
These questions reflect the persons ability to accurately understand the problem before deep diving into the technical details. From there, you can get more technical. "Client is receiving an HTTP 404 error." Great, rule out network since this is an application layer response...
just my .02.
On Fri, Jul 6, 2012 at 8:28 AM, <joseph.snyder@gmail.com> wrote:
I agree. Let the person talk do a few probing questions based off what they say. If you yourself have any value you should be able to tell if they have a chance.
Also I would prefer someone who says I don't know for sure but maybe something along these lines, and then wants to know the right answer. Passion is also important, if you are willing to hire someone who is in it for just a paycheck, save yourself the headache and get a contractor. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Matthew Palmer <mpalmer@hezmatt.org> wrote:
On Thu, Jul 05, 2012 at 11:04:05PM -0400, Robert E. Seastrom wrote:
Diogo Montagner <diogo.montagner@gmail.com> writes:
For screening questions (for 1st level filtering), IMO, the questions has to be straight to the point, for example:
1) What is the LSA number for an external route in OSPF?
This can have two answer: 5 or 7. So, I will accept if the candidate answer 5, 7 or 5 and 7. Later on (the next level of the interview), a techinical interviewer will chech if the candidate understand the differences of LSA 5 and 7.
Frankly, this feels a bit like asking what the 9th byte in an IP header is used for (it's TTL, but who's, uh, counting?) -- "That's why God gave us packet analyzers" should be counted as an acceptable answer. If not, you'll find yourself skipping over plenty of extremely well qualified candidates in favor of those who have crammed recently for some sort of exam in hopes of compensating for their short CV.
Ugh, I know someone (thankfully no longer a current colleague) who ardently *defends* his use of questions like "what does the -M option to ps do?" on the basis that "any senior person who knows what they're doing should know all the options to ps!". No, you useless tit, anyone who knows what they're doing should know how to read a bloody manpage.
Trivia tests get you hiring people who know trivia. Knowing trivia has it's productivity benefits, but if you can't apply it, it's useless.
- Matt
-- Politics and religion are just like software and hardware. They all suck, the documentation is provably incorrect, and all the vendors tell lies. -- Andrew Dalgleish, in the Monastery
-- -Matt Chung
"A client cannot access the website "http://xyz.com"
How does the user know that it cannot access the web site?
When did users become things?
Probably a candidate that made this mistake should be dismissed from consideration on that basis alone.
How do you know that the client is a person? --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
"A client cannot access the website "http://xyz.com"
How does the user know that it cannot access the web site?
When did users become things?
Probably a candidate that made this mistake should be dismissed from consideration on that basis alone.
How do you know that the client is a person?
Perhaps "What language is the client written in, and what Operating System is it running on?" would be a better response. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
DNA; Homo Sapien. Smart questions get smart answers. If you want HR to test technical knowledge just make a multiple choice test. (Course then you open a new can of worms). On Jul 6, 2012 3:16 PM, "Keith Medcalf" <kmedcalf@dessus.com> wrote:
"A client cannot access the website "http://xyz.com"
How does the user know that it cannot access the web site?
When did users become things?
Probably a candidate that made this mistake should be dismissed from consideration on that basis alone.
How do you know that the client is a person?
Perhaps "What language is the client written in, and what Operating
System is it running on?" would be a better response.
--- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
On Jul 6, 2012, at 12:23 PM, Tyler Haske wrote:
DNA; Homo Sapien.
Smart questions get smart answers.
If you want HR to test technical knowledge just make a multiple choice test. (Course then you open a new can of worms).
One of my employers did exactly this. I provided the answers I believed to be most likely what they were looking for in addition to a set of corrections to the questions. Owen
I've dealt with: 1, (yes, no comp, tablet, game console, or other device, other than non-internet capable HDTV. They had also just purchased our fastest service package. They got irate said were switching to our competitor, who were cheaper anyway. Good news for them, we don't do minimum service contracts. Bad news for them, the competitor does. ) 2, 3, 6, 7, 8 also 'user has no power but computer is on UPS or generator and network gear is not'. More than once in most cases. Lots and lots of laptops with wireless card switch flipped to off accidently. And while I've never had a user call because they are unable to access a website because they are dead, I have had a non-user call/email about receiving NDR emails regarding email boxes belonging to one of our users we removed after notification that the owner was deceased. That's happened a few times. My call on dealing with that was something along the lines of 'That email address has either been changed or the account associated with it disconnected, and we are not at liberty to discuss the issue further due to customer privacy policies' which is exactly what I say when the other possibilities are true. Actually I had something similar to 'the user is dead'. Guy calls in to complain his internet is down. We dig through our system, no record he's a customer. After lots of hemming and hawing, admits he leeches unsecured wireless connection off next door neighbor. Next door neighbor's next of kin just had cable/internet turned off as she passed away, left power on while the move stuff out of house, so wireless signal was still present. For a while I had 3 businesses in the same building that shared the same internet connection; However only one was listed on the account/paid the bill. Problem A) slow internet (metrics showing that their inbound or outbound is pegged, also the company paying bought the cheapest package available) Problem B) Cross business compromising of information, printing stuff in other offices (two of them were even direct competitors, effectivly) sharing drives across bussinesses, a virus outbreak that kept respreading through the network because one office didn't seem to care they had a worm, and C) company that owned/paid for connection had a tendancy to ignore late notices, because of billing schedule stuff the cutoff's would happen on Thursday, the person at that company with the authority to write checks only worked Mon-Wed ________________________________________ From: Owen DeLong [owen@delong.com] Sent: Friday, July 06, 2012 1:53 PM To: Keith Medcalf Cc: nanog@nanog.org Subject: Re: job screening question On Jul 6, 2012, at 11:41 AM, Keith Medcalf wrote:
My response would be "insufficient information provided for meaningful diagnosis".
The following could be issues: ... the user does not have a computer ... the computer is not turned on ... the keyboard is not plugged in ... the user is a quadraplegic and cannot use the mouse or keyboard ... the user is blind and cannot find the computer ... the user has a computer but is not connected to a network ... the monitor is not turned on ... the brightness is turned down too far on the monitor ... the user is dead
I would argue that the fact the user filed a ticket/contacted the helpdesk/whatever to raise the issue indicates that the user probably isn't dead. The rest are semi-legitimate somewhat amusing answers, but you missed many possibilities. When providing such a list of answers, always include an etc. at the end so as to indicate your understanding that the list is not complete. ;-)
How does the user know that it cannot access the web site?
When did users become things? Probably a candidate that made this mistake should be dismissed from consideration on that basis alone. Owen
-----Original Message----- From: Matt Chung [mailto:itsmemattchung@gmail.com] Sent: Friday, 06 July, 2012 08:20 To: joseph.snyder@gmail.com Cc: nanog@nanog.org Subject: Re: job screening question
A former manager of mine once told me you can gauge a persons understanding by the questions they ask and I personally agree with this statement. Most of us will be able to make a reasonable assessment of the person by listening to the content of their questions. I'm not looking for an immediate resolution, but trying to understand the thought process of the individual. I feel realistic scenarios provide some insight on the individual's analytical skills.
"A client cannot access the website "http://xyz.com". What do you do to troubleshoot this issue?"
Depending on the candidate, I've seen a variety of answers: 1) "Can you ping the device?" 2) "Can you access the gateway?" 3) "What does the running config look like on the router" 4) "Is there a firewall in between"
I believe these questions may be asked in the right context provided there is enough information to isolate the issue to the network however the statement is devoid of anything useful that would make the network suspect. I would like to hear some questions such as:
"are other websites accessible? Or is the only website the client is experiencing issues with?" "was the website working previously? when did it start happening?" "what does the client see on their screen ? are they getting an error?"
These questions reflect the persons ability to accurately understand the problem before deep diving into the technical details. From there, you can get more technical. "Client is receiving an HTTP 404 error." Great, rule out network since this is an application layer response...
just my .02.
On Fri, Jul 6, 2012 at 8:28 AM, <joseph.snyder@gmail.com> wrote:
I agree. Let the person talk do a few probing questions based off what they say. If you yourself have any value you should be able to tell if they have a chance.
Also I would prefer someone who says I don't know for sure but maybe something along these lines, and then wants to know the right answer. Passion is also important, if you are willing to hire someone who is in it for just a paycheck, save yourself the headache and get a contractor. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Matthew Palmer <mpalmer@hezmatt.org> wrote:
On Thu, Jul 05, 2012 at 11:04:05PM -0400, Robert E. Seastrom wrote:
Diogo Montagner <diogo.montagner@gmail.com> writes:
For screening questions (for 1st level filtering), IMO, the questions has to be straight to the point, for example:
1) What is the LSA number for an external route in OSPF?
This can have two answer: 5 or 7. So, I will accept if the candidate answer 5, 7 or 5 and 7. Later on (the next level of the interview), a techinical interviewer will chech if the candidate understand the differences of LSA 5 and 7.
Frankly, this feels a bit like asking what the 9th byte in an IP header is used for (it's TTL, but who's, uh, counting?) -- "That's why God gave us packet analyzers" should be counted as an acceptable answer. If not, you'll find yourself skipping over plenty of extremely well qualified candidates in favor of those who have crammed recently for some sort of exam in hopes of compensating for their short CV.
Ugh, I know someone (thankfully no longer a current colleague) who ardently *defends* his use of questions like "what does the -M option to ps do?" on the basis that "any senior person who knows what they're doing should know all the options to ps!". No, you useless tit, anyone who knows what they're doing should know how to read a bloody manpage.
Trivia tests get you hiring people who know trivia. Knowing trivia has it's productivity benefits, but if you can't apply it, it's useless.
- Matt
-- Politics and religion are just like software and hardware. They all suck, the documentation is provably incorrect, and all the vendors tell lies. -- Andrew Dalgleish, in the Monastery
-- -Matt Chung
This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited.
On Fri, Jul 06, 2012 at 09:19:48AM -0500, Matt Chung wrote:
A former manager of mine once told me you can gauge a persons understanding by the questions they ask and I personally agree with this statement. Most of us will be able to make a reasonable assessment of the person by listening to the content of their questions. I'm not looking for an immediate resolution, but trying to understand the thought process of the individual. I feel realistic scenarios provide some insight on the individual's analytical skills.
"A client cannot access the website "http://xyz.com". What do you do to troubleshoot this issue?"
it's blocking icmp echo.. dns works.. with multiple regional dns servers.. the page loads for me.. has a modern tcp/ip stack, probably linux judging by an initial window size of 14600 .. hosted on amazon web services... I'd imagine that they're unlikely to be blocking icmp totally.. and just the echo.. but there's still that possibility... (yeah I know it's just an example)
Depending on the candidate, I've seen a variety of answers: 1) "Can you ping the device?" 2) "Can you access the gateway?" 3) "What does the running config look like on the router" 4) "Is there a firewall in between"
heh,.. think i've been on the internet too long. i think from the destination site not working and what could be wrong with it.. then work my way back to the client. of course i completely skipped in my thinking that maybe other sites don't work too, and that there could be malware... and i didn't actually try going to the site with anything other than curl... i suppose a big part of that particular problem is figuring out if it's at their end - a greater problem - or an actual problem getting to the site.
I believe these questions may be asked in the right context provided there is enough information to isolate the issue to the network however the statement is devoid of anything useful that would make the network suspect. I would like to hear some questions such as:
"are other websites accessible? Or is the only website the client is experiencing issues with?" "was the website working previously? when did it start happening?" "what does the client see on their screen ? are they getting an error?"
yeah that's a good idea :) my order is probably assuming there may be a more complicated issue, when it could be a simple problem, which actually seems to be quite common from what i've experienced with technical people. oh! the network cable was unplugged!
These questions reflect the persons ability to accurately understand the problem before deep diving into the technical details. From there, you can get more technical. "Client is receiving an HTTP 404 error." Great, rule out network since this is an application layer response...
Some of those type problems have got a lot more complicated. Like - that could be a transparent proxy caching an HTTP 404... or the web site could be hosted in multiple locations and not syncing between them properly, which could still require some level of debugging.. or someone somehow managed to advertise the hosts subnet with a more preferred route, then doesn't have the content. Or say someone's decided to do something fancy like give different IP's back from DNS but giving internal IP addresses back to the local farm.. but they've decided to use Amazon DNS servers.. and set them to give IP .. but the customer happens to be using Amazon DNS servers because they're hosting a web site on Amazon, and for some reason thought it'd be a good idea.. and then the internal IP address of course doesn't have the content. I suppose that's still application level to some points of view. It doesn't make the site magically work though, or figure out what's causing it. Also from my experience, I don't tend to find out one website's not working unless it is working on/off or for other people, and the most common situation seems to be some kind of load balancing with one mirror not working, and I find it helpful to check from a few locations. And sometimes doing dns lookups, on multiple DNS servers, and seeing a different IP and using curl -x <ip>:80 seems to be the easiest way to check this. But that's assuming a transparent proxied network, which tends to mean MTU issues show up as instead "banking web sites aren't working". Which can show up sometimes when people change routers to one not doing MSS-clamping, and operate at 1492 MTU... The issue is significant enough, and the problem hard enough for helpdesk type people to diagnose that it's common for MSS clamping to be set at a network level for networks with a significant amount of people with < 1500 MTU. Ben.
On 06/07/2012 16:12, valdis.kletnieks@vt.edu wrote:
On Fri, 06 Jul 2012 17:42:42 +1000, Matthew Palmer said:
Ugh, I know someone (thankfully no longer a current colleague) who ardently *defends* his use of questions like "what does the -M option to ps do?" on
Is that an African ps or a European ps? ;)
I'll admit that I once asked a question like in an interview, but it was only because the candidate had said that he was an expert with the "tar" command. If you're going to be that full of poop on a CV, you should expect to be called up on it. [against my advice, the candidate was hired and was a disaster. I left the company shortly afterwards.] Nick
On Fri, Jul 6, 2012 at 11:50 AM, Nick Hilliard <nick@foobar.org> wrote:
I'll admit that I once asked a question like in an interview, but it was only because the candidate had said that he was an expert with the "tar" command. If you're going to be that full of poop on a CV, you should expect to be called up on it.
[against my advice, the candidate was hired and was a disaster. I left the company shortly afterwards.]
That sounds like the guy who on his resume under "training" listed the 3-day course and certification he got in configuring Kentrox CSU/DSUs. The limited space one has on a resume to present oneself and that's what he chose to tell me. I understand that maybe his company made him do it but there are some things you just don't admit to. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Fri, 6 Jul 2012, Nick Hilliard wrote:
On 06/07/2012 16:12, valdis.kletnieks@vt.edu wrote:
On Fri, 06 Jul 2012 17:42:42 +1000, Matthew Palmer said:
Ugh, I know someone (thankfully no longer a current colleague) who ardently *defends* his use of questions like "what does the -M option to ps do?" on Is that an African ps or a European ps? ;) I'll admit that I once asked a question like in an interview, but it was only because the candidate had said that he was an expert with the "tar" command. If you're going to be that full of poop on a CV, you should expect to be called up on it.
This is what baffles me. People keep putting stuff on their resume that they simply don't know anything about. TCP/IP expert, yet they don't know SYN/SYNACK/ACK or subnetting. HTTP expert but they don't know what a 200 response is. -Dan
On Fri, 06 Jul 2012 15:07:51 -0700, goemon@anime.net said:
This is what baffles me. People keep putting stuff on their resume that they simply don't know anything about. TCP/IP expert, yet they don't know SYN/SYNACK/ACK or subnetting. HTTP expert but they don't know what a 200 response is.
The Friday afternoon cynic in me says it's because it's a move with positive paybacks. There's 3 basic possibilities: 1) You send the puffed resume to a company with clue, it gets recognized as puffed, and you don't get the job. Zero loss, you weren't going to get that job anyhow. 2) You send a boring unpuffed resume to a company sans clue. They recognize it as boring because there's only 3 buzzwords on 2 pages, and you don't get the job. Loss. 3) You send a puffed resume, and the guy doing the hiring doesn't know what the 3-packet mating call of the Internet is *either*. Win.
Pascal's wager.. almost :) On Fri, Jul 6, 2012 at 7:25 PM, <valdis.kletnieks@vt.edu> wrote:
On Fri, 06 Jul 2012 15:07:51 -0700, goemon@anime.net said:
This is what baffles me. People keep putting stuff on their resume that they simply don't know anything about. TCP/IP expert, yet they don't know SYN/SYNACK/ACK or subnetting. HTTP expert but they don't know what a 200 response is.
The Friday afternoon cynic in me says it's because it's a move with positive paybacks. There's 3 basic possibilities:
1) You send the puffed resume to a company with clue, it gets recognized as puffed, and you don't get the job. Zero loss, you weren't going to get that job anyhow.
2) You send a boring unpuffed resume to a company sans clue. They recognize it as boring because there's only 3 buzzwords on 2 pages, and you don't get the job. Loss.
3) You send a puffed resume, and the guy doing the hiring doesn't know what the 3-packet mating call of the Internet is *either*. Win.
On 06/07/2012 23:25, valdis.kletnieks@vt.edu wrote:
The Friday afternoon cynic in me says it's because it's a move with positive paybacks. There's 3 basic possibilities:
1) You send the puffed resume to a company with clue, it gets recognized as puffed, and you don't get the job. Zero loss, you weren't going to get that job anyhow.
2) You send a boring unpuffed resume to a company sans clue. They recognize it as boring because there's only 3 buzzwords on 2 pages, and you don't get the job. Loss.
3) You send a puffed resume, and the guy doing the hiring doesn't know what the 3-packet mating call of the Internet is *either*. Win.
or: 4) you get caught out in the interview as being puffed up, but the company hires you anyway despite strongly worded objections from the interviewer, causing the interviewer's eyes to spin in their sockets at the inanity of the decision. You then spend your entire employment at the company proving your ineptitude beyond all possible doubt. I think this is a win, is it? Nick
On Sat, 07 Jul 2012 00:07:57 +0100, Nick Hilliard said:
4) you get caught out in the interview as being puffed up, but the company hires you anyway despite strongly worded objections from the interviewer, causing the interviewer's eyes to spin in their sockets at the inanity of the decision. You then spend your entire employment at the company proving your ineptitude beyond all possible doubt.
I think this is a win, is it?
Yeah - it's a better gig than you would have landed otherwise, isn't it? :)
On Fri, Jul 6, 2012 at 4:07 PM, Nick Hilliard <nick@foobar.org> wrote:
On 06/07/2012 23:25, valdis.kletnieks@vt.edu wrote:
The Friday afternoon cynic in me says it's because it's a move with positive paybacks. There's 3 basic possibilities:
1) You send the puffed resume to a company with clue, it gets recognized as puffed, and you don't get the job. Zero loss, you weren't going to get that job anyhow.
2) You send a boring unpuffed resume to a company sans clue. They recognize it as boring because there's only 3 buzzwords on 2 pages, and you don't get the job. Loss.
3) You send a puffed resume, and the guy doing the hiring doesn't know what the 3-packet mating call of the Internet is *either*. Win.
or:
4) you get caught out in the interview as being puffed up, but the company hires you anyway despite strongly worded objections from the interviewer, causing the interviewer's eyes to spin in their sockets at the inanity of the decision. You then spend your entire employment at the company proving your ineptitude beyond all possible doubt.
I think this is a win, is it?
There's also 5) Didn't have enough clue about the real world to know you were puffing your resume up. 6) Puffed it up a little (worked with Cisco routers, but in the 7200 era, and hasn't categorized skills as recent / older), but hasn't outright lied. I get resumes all the time that are off in some direction. Usually 5) - inflated due to lack of industry scope understanding, some 6). Neither of these is a disqualifier per se. The question is what do they do when you start asking questions and putting it into context. If they put old skills down and admit it, that's fine, just ask them how recent all the various things are and note it down. If they don't have a clue ("But we had IPv6 coursework in university last semester!") they may be an OK beginner. If you're hiring for a junior position that's fine. If you're hiring for a more senior one, I usually let them down gently and explain the scope and breadth of the things they put down and help them aim their resume more accurately in the future. I've had people try to BS me in the interview or outright lie on the resume beforehand. A couple of each out of the last... 325 or so people I've interviewed? Something like that. Not very many. Easy to spot. They were not hired. -- -george william herbert george.herbert@gmail.com
On Jul 6, 2012, at 4:16 PM, George Herbert <george.herbert@gmail.com> wrote:
6) Puffed it up a little (worked with Cisco routers, but in the 7200 era, and hasn't categorized skills as recent / older), but hasn't outright lied.
The 7200 is still a heavily used platform today. It has no correlation with current skill sets IMHO.
On Fri, Jul 6, 2012 at 4:43 PM, Steven Noble <snoble@sonn.com> wrote:
On Jul 6, 2012, at 4:16 PM, George Herbert <george.herbert@gmail.com> wrote:
6) Puffed it up a little (worked with Cisco routers, but in the 7200 era, and hasn't categorized skills as recent / older), but hasn't outright lied.
The 7200 is still a heavily used platform today. It has no correlation with current skill sets IMHO.
Would s/7200/2500/g be an adequate correction? I know of customers who still have 7200s as well, but in the context of ISP network engineering... Perhaps I'm wrong, but my impression is people on this list have generally moved on by now. Context matters. One can always point to lingering examples of older technology (if nowhere else, the Computer History Museum 8-). The question is whether the skill is relevant in context. I built a nationwide T-1 backbone out of Livingston IRXes once (in the early 90s) - the IRX left my resume by the late 1990s. I know of at least one still humming away in a closet, but it's not a relevant technology. I also learned (some) shell commands on a Vax 11/750 when they were new and used Apple II's when they were new, and so on. None of these are resume-appropriate now, unless I want a job at the Computer History Museum. If people don't bother to clean up the resume, either they don't understand what's relevant now, or they don't care, or they're trying to hide something. -- -george william herbert george.herbert@gmail.com
On Jul 6, 2012, at 5:04 PM, George Herbert <george.herbert@gmail.com> wrote:
On Fri, Jul 6, 2012 at 4:43 PM, Steven Noble <snoble@sonn.com> wrote:
On Jul 6, 2012, at 4:16 PM, George Herbert <george.herbert@gmail.com> wrote:
6) Puffed it up a little (worked with Cisco routers, but in the 7200 era, and hasn't categorized skills as recent / older), but hasn't outright lied.
The 7200 is still a heavily used platform today. It has no correlation with current skill sets IMHO.
Would s/7200/2500/g be an adequate correction?
I know of customers who still have 7200s as well, but in the context of ISP network engineering... Perhaps I'm wrong, but my impression is people on this list have generally moved on by now.
Context matters. One can always point to lingering examples of older technology (if nowhere else, the Computer History Museum 8-). The question is whether the skill is relevant in context.
I built a nationwide T-1 backbone out of Livingston IRXes once (in the early 90s) - the IRX left my resume by the late 1990s. I know of at least one still humming away in a closet, but it's not a relevant technology. I also learned (some) shell commands on a Vax 11/750 when they were new and used Apple II's when they were new, and so on. None of these are resume-appropriate now, unless I want a job at the Computer History Hi George,
I sent the message too soon :( I meant to say more about how the equipment is not as important as the drive and willingness to work with what you have. I have talked to companies who have job openings many months old for people who absolutely exist in the silicon valley. The hiring company just thinks the people who apply are over or under qualified. All of the great coders, engineers, etc started somewhere. The main thing that separates them from the posers and acronym namers is the willingness to grow, learn and dig in. I like people who run 2500s in their house, or dd-wrt. It shows they are willing to try something and learn.
On Fri, Jul 6, 2012 at 9:22 PM, Steven Noble <snoble@sonn.com> wrote:
I have talked to companies who have job openings many months old for people who absolutely exist in the silicon valley. The hiring company just thinks the people who apply are over or under qualified.
I thought someone was overqualified once. My decision was overridden. I turned out to be very glad it was. He didn't fit the role I thought I needed but I was able to turn him loose with minimal supervision. And I was able to go on vacation. :) That was so much more valuable. Now I know: tell the candidate about the work, all the work not just the job you thought you would hire for, and let him tell you whether any of it is beneath him. As long as you get all the skills you need on the team you can juggle the tasking. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Fri, Jul 06, 2012 at 09:36:47PM -0400, William Herrin wrote:
On Fri, Jul 6, 2012 at 9:22 PM, Steven Noble <snoble@sonn.com> wrote:
I have talked to companies who have job openings many months old for people who absolutely exist in the silicon valley. The hiring company just thinks the people who apply are over or under qualified.
I thought someone was overqualified once. My decision was overridden. I turned out to be very glad it was. He didn't fit the role I thought I needed but I was able to turn him loose with minimal supervision. And I was able to go on vacation. :) That was so much more valuable.
I've seen people turned away for being "overqualified", when I would have hired them in a heartbeat. The HR types seem unable to comprehend that "overqualified" is not a bad thing, especially in the current economic climate, and that it includes "qualified". Being able to bring someone in and then take vacation time without having to worry about things going casters-up is very valuable indeed.
Now I know: tell the candidate about the work, all the work not just the job you thought you would hire for, and let him tell you whether any of it is beneath him. As long as you get all the skills you need on the team you can juggle the tasking.
Unless you have a policy that "Slot A only does Slot A work" stuffed up some orifice. I've been there, and it is both stultifying and limiting. -- Mike Andrews, W5EGO mikea@mikea.ath.cx Tired old sysadmin
On 12-07-09 12:57 PM, Mike Andrews wrote:
Unless you have a policy that "Slot A only does Slot A work" stuffed up some orifice. I've been there, and it is both stultifying and limiting. Further to the above wisdom, if you truly care about your work it will either drive you crazy as you force yourself to fix things that aren't your problem, or as you start to force yourself not to care about someone else's crappy work.
-- Looking for (employment|contract) work in the Internet industry, preferrably working remotely. Building / Supporting the net since 2400 baud was the hot thing. Ask for a resume! ispbuilder@gmail.com
On Fri, 06 Jul 2012 17:04:16 -0700, George Herbert said:
If people don't bother to clean up the resume, either they don't understand what's relevant now, or they don't care, or they're trying to hide something.
OK. I admit it. My resume still lists that I spent a few years hacking assembler code for OS/VS1 and HASP 30 years ago. But it's there as one endpoint, that wanders from there, to IBM's VM, to SunOS, and Sendmail, some AIX and 8 or 9 other Unix flavors (anybody else remember UTX/32? If so, we need to share a few beers and swap stories:), computer security, to supporting SGI virtual reality systems in the late 90s (IR2 graphics pipes, woo-hoo), to Linux (my code is in every Android phone out there. OK, only a few dozen lines, but still ;), helped build a top-5 supercomputer and a few other things along the way, and now I mostly do high-performance storage infrastructure. Oh, and a paper in the IEEE Transactions on Nuclear Science along the line. ;) So no. OS/VS1 isn't relevant now. What *is* relevant now is that I have 3 decades of experience at being tossed new stuff by the boss and getting up to speed on it fast. The day my boss walks into my office and says "We've got this new..." and I'm unable to get up to speed on it faster than anybody else in the shop is the day it's time for me to retire. ;) So the OS/VS1 reference stays. ;)
On Fri, 6 Jul 2012, George Herbert wrote:
If people don't bother to clean up the resume, either they don't understand what's relevant now, or they don't care, or they're trying to hide something.
Or they want to show they've been doing it long enough that they have experience working with older gear younger people may not have even heard of. I have experience with Portmasters, Pipelines, and home built Linux multiport dialup PPP servers. None are relevant today. IMO, at least the latter demonstrates some skills. Rolling your own 80-port dialup server in 1995 wasn't just "yum install dialup-server" :) I don't mention Portmasters or Pipelines on my resume, but I do have Livingston and Ascend in the list of [many obsolete] router brands I have experience with. Is that really totally irrelevant now? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On 07/06/2012 16:16, George Herbert wrote:
On Fri, Jul 6, 2012 at 4:07 PM, Nick Hilliard <nick@foobar.org> wrote:
On 06/07/2012 23:25, valdis.kletnieks@vt.edu wrote:
The Friday afternoon cynic in me says it's because it's a move with positive paybacks. There's 3 basic possibilities:
1) You send the puffed resume to a company with clue, it gets recognized as puffed, and you don't get the job. Zero loss, you weren't going to get that job anyhow.
2) You send a boring unpuffed resume to a company sans clue. They recognize it as boring because there's only 3 buzzwords on 2 pages, and you don't get the job. Loss.
3) You send a puffed resume, and the guy doing the hiring doesn't know what the 3-packet mating call of the Internet is *either*. Win.
or:
4) you get caught out in the interview as being puffed up, but the company hires you anyway despite strongly worded objections from the interviewer, causing the interviewer's eyes to spin in their sockets at the inanity of the decision. You then spend your entire employment at the company proving your ineptitude beyond all possible doubt.
I think this is a win, is it?
There's also
5) Didn't have enough clue about the real world to know you were puffing your resume up.
6) Puffed it up a little (worked with Cisco routers, but in the 7200 era, and hasn't categorized skills as recent / older), but hasn't outright lied.
7) Were the beneficiary of some professional resume service/headhunter. "You know how to spell 'aych-tee-tee-pee'? Let's list that!" -- If you're never wrong, you're not trying hard enough
On Fri, Jul 06, 2012 at 11:12:50AM -0400, valdis.kletnieks@vt.edu wrote:
On Fri, 06 Jul 2012 17:42:42 +1000, Matthew Palmer said:
Ugh, I know someone (thankfully no longer a current colleague) who ardently *defends* his use of questions like "what does the -M option to ps do?" on
Is that an African ps or a European ps? ;)
That was actually the reason why he picked on ps in particular -- because it had two completely different command sets and yes, he expects candidates to know the difference. - Matt -- Ideas are like rabbits. You get a couple and learn how to handle them, and pretty soon you have a dozen. -- John Steinbeck
Ok, so I read over Williams OP... I have 25 years IT experience... I've applied for a few jobs in my time... I thought to myself "I'll have a crack with a few comments!!!"... ....then I read down the next 30 posts and decided that perhaps I didn't really know enough about networking to really comment... ...and perhaps I needed a bit more grey hair and eat more RFCs for breakfast... ...then I read down the next 30 posts and realised that I really didn't know enough about computing to comment.... ...and perhaps my problem wasn't lack of grey hair, but just to much hair... ...Talk about a bunch of intimidating uber geeks! :) I suspect that when I read down the next 30 posts I'll just back away from the computer slowly knowing that I'm just not smart enough to use this device. But seriously guys, great thread with tons of really interesting stuff and a bunch of history. D On 6/07/2012 5:02 a.m., William Herrin wrote:
Hi folks,
I gave my HR folks a screening question to ask candidates for an IP expert position. I've gotten some "unexpected" answers, so I want to do a sanity check and make sure I'm not asking something unreasonable. And by "unexpected" I don't mean naively incorrect answers, I mean oh-my-God-how-did-you-get-that-cisco-certification answers.
The question was:
You implement a firewall on which you block all ICMP packets. What part of the TCP protocol (not IP in general, TCP specifically) malfunctions as a result?
My questions for you are:
1. As an expert who follows NANOG, do you know the answer? Or is this question too hard?
2. Is the question too vague? Is there a clearer way to word it?
3. Is there a better screening question I could pass to HR to ask and check the candidate's response against the supplied answer?
Thanks, Bill Herrin
-- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699
On Thu, Jul 5, 2012 at 10:02 AM, William Herrin <bill@herrin.us> wrote:
Hi folks,
I gave my HR folks a screening question to ask candidates for an IP expert position. I've gotten some "unexpected" answers, so I want to do a sanity check and make sure I'm not asking something unreasonable. And by "unexpected" I don't mean naively incorrect answers, I mean oh-my-God-how-did-you-get-that-cisco-certification answers.
The question was:
You implement a firewall on which you block all ICMP packets. What part of the TCP protocol (not IP in general, TCP specifically) malfunctions as a result?
My questions for you are:
1. As an expert who follows NANOG, do you know the answer? Or is this question too hard?
I perused the thread but lots of people have mentioned mtu discovery but not what happens on TCP and an issue with mss but not what happens - if there is a smaller mtu along the path the receive window fills up on the host initiating the connection and then the connection just times out.
2. Is the question too vague? Is there a clearer way to word it?
It is way to confusing and may be better in a two part question and work up to it. Instead of asking if all ICMP is blocked put into to Type/Code with out giving away that it's the Maybe for HR ask more text book stuff like name the tcp flags or describe the tcp connection closing or what field determines if a packet can be fragmented and then compare that to how it works in IPv6. How big is the TCP or IP headers? How many with options? etc...
3. Is there a better screening question I could pass to HR to ask and check the candidate's response against the supplied answer?
Thanks, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
participants (36)
-
Ben Aitchison -
Daniel Roesen -
Darius Jahandarie -
David Coulson -
Dennis -
Derek Ivey -
Diogo Montagner -
Don Gould -
Doug Barton -
Eric J Esslinger -
George Herbert -
goemon＠anime.net -
James M Keller -
Jared Mauch -
jim deleskie -
Jon Lewis -
joseph.snyder＠gmail.com -
Keith Medcalf -
Leo Bicknell -
Matt Chung -
Matthew Palmer -
Mike -
Mike Andrews -
Nick Hilliard -
Oliver Garraux -
Owen DeLong -
Ray Soucy -
Ray Wong -
Robert E. Seastrom -
Scott Howard -
Steven Noble -
Terry Baranski -
Thomas York -
Tyler Haske -
valdis.kletnieks＠vt.edu -
William Herrin