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?

Bill Herrin

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

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?


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.

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

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." :slight_smile:

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.

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.

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.



So, I'm curious, and others probably are too. What's the most popular 'wrong' answer?



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

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. :slight_smile:

"This would block all IP traffic." is not a correct answer. It's not
even a naively incorrect answer.

Bill Herrin

This is exactly the issue 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,

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


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.

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.

Isn't MTU discovery on IP and not TCP?


If you want to overthink the question, the failure in the TCP protocol
is that it doesn't adjust the MSS to match the path MTU. It continues
to rely on the incorrect path MTU estimate, sending too-large packets
which will never arrive. This happens because TCP doesn't receive a
notification that the path MTU estimate has changed from the default
because the lower layer PMTUD algorithm never receives the expected
ICMP packet.

This is, incidentally, is a detail I'd love for one of the candidates
to offer in response to that question. Bonus points if you discuss MSS
clamping and RFC 4821.

The less precise answer, path MTU discovery breaks, is just fine.

Bill Herrin

Precisely! and if I understand correctly, a non-techinical person within HR is expected to hear this answer and relay it to you? That is more than a long shot. Unless of course they have photographic memories, are great typists or perhaps do "short hand".


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